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.) ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
