Re: [PATCH] x86/hvm: Provide list of emulated features in HVM CPUID leaf

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 02/02/2016 23:30, Boris Ostrovsky wrote:
> On 02/02/2016 06:22 PM, Andrew Cooper wrote:
>> On 02/02/2016 23:17, Boris Ostrovsky wrote:
>>> Hypervisor may choose which features to emulate for HVMlite guests.
>>> Guest will query the HVM CPUID leaf to find out what is available.
>>>
>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Roger also submitted a patch to do this.  However, it is not
>> appropriate, so was dropped.
>>
>> An HVMLite domain should assume there are no emulated devices.  The very
>> old legacy devices will never be implemented, and any others we care
>> about possibly implementing in the future have APCI-based ways of
>> indicating support.
>
> OK, so I wasn't the first one to come up with this ;-)
>
> I think for now I mostly care about APIC and for that I can use HW
> CPUID bit (which I believe is cleared for HVMlite guests).

The APIC bit in cpuid is magic and specified as a fast forward of the
APICBASE_MSR enable bit.

Therefore, the correct architectural behaviour is for this bit to be
clear if the local APIC is disabled, or indeed not implemented.

With my maintainers hat on, I will reject any attempt to introduce
non-architectural behaviour; at the moment I am dealing with the
stupidity that is the PV XSAVE interface, where broken bugfix piled on
top of broken bugfix has resulted in a situation where many Linux PV
guests crash if provided with architecturally correct behaviour of the
OSXSAVE cpuid bit (yet another magic one).

> The trouble is that I need to present Linux as having APIC (boot code
> doesn't feel good if !cpu_has_apic) so I'll need to keep no-APIC
> emulation private to Xen-related code. Which is doable.

I see two choices.

1) Require that Linux DMLite guests require a Local APIC, and we allow
that to be a configured option.  Exposing APIC definitely makes sense
longer term, because APICV hardware acceleration outperforms the
hypercall-based method.

2) Find a way of telling the Linux boot path "trust me - here is an APIC
driver - dont go looking under the hood".  Possibly by registering a
cpuid pvop which re-inserts the APIC bit, although this is liable to
cause the boot code to then inspect the APICBASE_MSR, which will cause
it to blow up slightly later on.

~Andrew