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

[Fredrik Noring <noring@nocrew.org>]

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