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

From: "Jan Beulich" <JBeulich@suse.com>
To: Tim Deegan <tim@xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	boris.ostrovsky@oracle.com, xen-devel@lists.xenproject.org,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map
Date: Mon, 30 Jan 2017 03:43:22 -0700	[thread overview]
Message-ID: <588F26DA0200007800134F09@prv-mh.provo.novell.com> (raw)
In-Reply-To: <20170127194355.GA82405@deinos.phlegethon.org>

>>> On 27.01.17 at 20:43, <tim@xen.org> wrote:

>> Despite being owned by the guest, this TSS is actually managed by
> Xen.
>> It should be initialised to defaults each time Xen needs to use it
> on
>> behalf of the guest.
> 
> At 14:35 +0000 on 27 Jan (1485527708), Andrew Cooper wrote:
>> On 27/01/17 14:01, Tim Deegan wrote:
>> > 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.
>> 
>> That is a good point.  Nothing prevents a guest exiting vm86 mode, and
>> using a task switch to move to a new tss, which will cause Xen to write
>> state back into the vm86_tss, making it no longer a zeroed block of memory.
>> 
>> Despite being owned by the guest, this TSS is actually managed by Xen. 
>> It should be initialised to defaults each time Xen needs to use it on
>> behalf of the guest.
> 
> But it's already in an E820 reserved block - if the guest overwrites
> it (with a task switch or otherwise) it will break real-mode support,
> but this is no worse than nobbling any other part of the BIOS state.
> 
> If we're making it non-zero, I can see an argument for having Xen init
> the contents once (maybe when the HVM param is written?) so that it
> matches what Xen expects of it.  But resetting it every time we use it
> would be overkill.

That wasn't the point Andrew was making, I think. A task switch
initiated by the guest would make the hypervisor write into that
TSS (as the outgoing one). Of course any sane guest would do an
LTR first (or else it would risk memory near address zero to get
clobbered on real hardware).

Jan

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