Re: [Xen-devel] about fully UMIP support in Xen

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/04/17 15:27, Jan Beulich wrote:
>>>> On 19.04.17 at 16:17, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 19/04/17 15:06, Jan Beulich wrote:
>>>>>> On 19.04.17 at 15:49, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> If a PV kernel is aware of UMIP and turns UMIP on, #GPs from userspace
>>>> should be bounced to the kernel, and #GPs from kernel space (as it is
>>>> ring-deprivileged) must be emulated and execute successfully.
>>>>
>>>> If Xen is using UMIP to protect itself, it needs to emulate and fake up
>>>> the information to both guest userspace and kernelspace.
>>>>
>>>> If both Xen and the PV kernel turn on UMIP, Xen needs to bounce
>>>> userspace #GPs to the guest kernel, and fake up information for the
>>>> guest kernel.
>>> I disagree in one point: If the guest kernel enabled UMIP, it being
>>> PV it should take care not to execute any of the covered insns (it
>>> has no use for them anyway). I see no reason to emulate anything
>>> in that case - emulation is needed only to keep _unaware_
>>> environments working.
>> That will involve someone ensuring that new PVops get introduced and used.
>>
>> Amongst other things, the current Linux doublefault handler uses sgdt.
> But a PV guest would never get to see a #DF.

It currently doesn’t, but that is a mishap of the current PV ABI
behaviour.  A PV guest *should* see things like #NP for missing entries
in its virtual IDT or non-present segments, rather than the current
domain_crash() it gets, and with that comes the expectation of faults
combining to inject #DF.

~Andrew

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