Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

[Tim Deegan <tim@xxxxxxx>]

Hi,

At 13:46 +0000 on 27 Jan (1485524765), Andrew Cooper wrote:
> The actual behaviour can be determined by putting the TSS on a page
> boundary, making the previous frame non-readable via EPT, and seeing
> whether an EPT violation occurs.

Indeed.  Or likewise with normal pagetables. 

> > Yes, I wonder about the I/O bitmap too.  We don't provide one, or even
> > enough space for a full one, but the current SDM is pretty clear that
> > the CPU will try to check it in virtual 8086 mode.
> >
> > It may be that all the ports actually used happen to fall in the 128
> > bytes of zeros that we provide.
> 
> With an offset of 0, we actually provide 256 bytes of zeros in the
> bitmap within the TSS limit.

Sure, or at least 128 bytes of zeros and another 128 bytes of something.

> > Or possibly (both for this and the interrupt bitmap) we are causing
> > #GP and somehow ending up exiting-and-emulating.  But I don't see
> > quite what the path is for that.
> 
> We set IOPL to 3 as well as when entering vm86 to fake up real mode. 
> This bypasses all I/O bitmap checks (a properly common to ring 3
> protected tasks as well - See specifically 20.2.7 "Sensitive
> Instructions"), which means the IN/OUT instructions end up directly at
> the relevant vmexit case.

20.2.8.1 makes it clear that this is not the case -- in virtual 8086
mode all IN/OUT ops check the bitmap event with IOPL == CPL.

Tim.

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