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

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

El 3/2/16 a les 1:17, Andrew Cooper ha escrit:
> 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@xxxxxxxxxx>
>>> 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 ;-)

Hehe, no I think I've posted the exact same patch a week ago:

http://marc.info/?l=xen-devel&m=145339515912038

>> 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 have to do the same for FreeBSD, I have to manually switch the APIC
cpuid bit, or else FreeBSD refuses to do SMP initialization. IMHO, what
we currently do (no APIC cpuid bit) is correct, and when a local APIC is
available the bit will indeed be enabled.

> 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.

This is what I aim to do long term, that is provide an emulated local
APIC. The plan was to then also provide ACPI tables in order to notify
the presence of the local and IO APICs (we are going to need both if we
plan to do pci-passthrough of devices with PCI interrupts). Of course
the APIC cpuid bit will also be enabled in this case.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel