Re: [PATCH v14 00/20] Introduce PVH domU support

[George Dunlap <george.dunlap@eu.citrix.com>]

On 08/11/13 17:01, Tim Deegan wrote:
> At 15:53 +0000 on 08 Nov (1383922404), George Dunlap wrote:
>> On 08/11/13 15:41, George Dunlap wrote:
>>> On 04/11/13 17:34, Tim Deegan wrote:
>>>> At 17:23 +0000 on 04 Nov (1383582187), George Dunlap wrote:
>>>>> On 04/11/13 16:59, Konrad Rzeszutek Wilk wrote:
>>>>>>> This also means no support for "legacy" forced invalid ops -- only
>>>>>>> native
>>>>>>> cpuid is supported in this series.
>>>>>> OK.
>>>>> (FWIW, support for legacy forced invalid ops was requested by Tim.)
>>>> I was worried about existing PV kernel code that used the fake-CPUID,
>>>> which would break if the 'core' kernel code went from PV to PVH.  But
>>>> I guess I could be convinced that such kernel code is buggy? Really,
>>>> the high-order bit was consistency.  The version I commented on
>>>> supported them for user-space but not for kernel, which seemed like
>>>> risking trouble for no benefit.
>>> Oh right -- I think Mukesh we do need to support forced invalid ops
>>> for user space so that we can use the same xen tools binaries on PV
>>> and PVH kernels.
>>>
>>> Hmm, Mukesh / Konrad, what tools are you actually thinking about
>>> here?  Are these Oracle-specific tools?  I can't seem to find
>>> XEN_CPUID or XEN_EMULATE_PREFIX anywhere in the tools/ directory of
>>> the xen repo...
>> It's misc/xen-detect.c, for the curious (which helpfully does not use
>> the macros above).
>>
>> Handling forced invalid ops it is, then.
> The xen-detect code tries real CPUID first, so not supporting the fake
> CPUID doesn't actually affect it at all.  That's why I could be
> convinced that detection failures were a guest-side bug.
>
> It would affect older code that _only_ tired the fake CPUID, or code
> that for some reason needed to behave differently on PV vs HVM (though
> it's not at all clear that on PVH such code should use the 'PV'
> behaviour.

Yes, taking a closer look, xen-detect in a PVH domain will behave the 
same as in an HVM domain:

# ./xen-detect
Running in HVM context on Xen v4.4.

I don't think this is a big deal; to be robust your system should be 
able to operate properly in an HVM (or PVHVM) domU.

I'll leave this out for now, but I'll put a note in the cover letter and 
in the doc file so we don't forget about it.

  -George