qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R


From: Fredrik Noring
Subject: Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900
Date: Fri, 26 Oct 2018 15:42:00 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

Hi Maciej,

>  I'm not sure if every single random vendor-specific instruction (or a 
> bunch of) deserves its own ASE designation, be it internal or externally 
> exposed.  I think the MMI set being a substantial architectural feature 
> makes sense to be shown in /proc/cpuinfo (in Linux), but I don't think 
> there's much more about it.  It's limited to 2 implementations only, so 
> internally I think it can well be handled with a macro or static inline 
> function (as appropriate) which boil down to (CPU_R5900 || CPU_TX79).

Are there benefits in leaving out features? Their utility, such as
in choosing compiler options, may not correlate with their (lack of)
architectural weight.

A random pc, for instance, comes fully dressed flying the flags of

        fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
        cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
        pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts
        rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni
        pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16
        xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer
        aes xsave avx lahf_lm epb kaiser tpr_shadow vnmi flexpriority
        ept vpid xsaveopt dtherm ida arat pln pts

in its /proc/cpuinfo. It also has a bugs field with

        cpu_meltdown spectre_v1 spectre_v2

where the R5900 could have an entry for its short loop bug.

>  And if you run out of bits for ASEs regardless, then I suggest just to 
> expand the field in question.  In QEMU you can rely on the presence of the 
> `uint64_t' data type, so with only 8 bits exhausted you're far from 
> getting into trouble.

DisasContext::insn_flags is already uint64_t, where bits 63..56 are
reserved for vendor-specific ASEs. Of course, one could organise them
differently, especially since they may be mutually exclusive, or one
could use a new ASE-specific field for them.

Fredrik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]