On 10/02/2020 14:00, Jan Beulich wrote:
> On 10.02.2020 14:56, Andrew Cooper wrote:
>> On 10/02/2020 13:47, Jan Beulich wrote:
>>> On 10.02.2020 14:29, Andrew Cooper wrote:
>>>> On 10/02/2020 13:22, Jan Beulich wrote:
>>>>> On 08.02.2020 16:19, Andrew Cooper wrote:
>>>>>> --- a/docs/misc/pvh.pandoc
>>>>>> +++ b/docs/misc/pvh.pandoc
>>>>>> @@ -23,7 +23,7 @@ following machine state:
>>>>>>   * `cs`: must be a 32-bit read/execute code segment with a base of ‘0’
>>>>>>     and a limit of ‘0xFFFFFFFF’. The selector value is unspecified.
>>>>>>  
>>>>>> - * `ds`, `es`: must be a 32-bit read/write data segment with a base of
>>>>>> + * `ds`, `es`, `ss`: must be a 32-bit read/write data segment with a 
>>>>>> base of
>>>>>>     ‘0’ and a limit of ‘0xFFFFFFFF’. The selector values are all 
>>>>>> unspecified.
>>>>> Wouldn't this want accompanying with an adjustment to
>>>>> xen/arch/x86/hvm/domain.c:check_segment(), which right now
>>>>> isn't in line with either old or new version of this doc?
>>>> What do you thing is missing?  It too is written with the expectation of
>>>> %es being set up, which I checked before sending this patch.
>>> The function for example looks to permit zero segment attributes
>>> for both DS and ES. It also looks to permit non-writable
>>> attributes for both, and a non-readable CS.
>> It is not a PVH-auditing function.
>>
>> It is reachable from plain HVM guests, and is only supposed to be a
>> minimum set of checks to prevent a vmentry failure of the
>> newly-initialised vcpu state.  (Whether it actually meets this goal is a
>> separate matter.)
> Well, that's fine, but what other place am I missing then where the
> documented restrictions actually get enforced? Or if we don't mean
> to enforce them, then perhaps there should be a distinction in the
> doc between "must" and "should"?

The written ABI is the ABI.  Conforming implementations must (as in
must) follow the rules.

The domain builder(s) are the only places which knows that the PVH start
ABI is in use.

Xen does not know, and therefore cannot legitimately check.  This
hypercall is used for more than just the PVH starting ABI, so must (as
it must) not have any PVH-ABI checks.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to