Re: [Xen-devel] [PATCH for-4.5 v6 00/16] Xen VMware tools support

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 09/22/14 11:52, Andrew Cooper wrote:
> On 22/09/14 16:34, Ian Campbell wrote:
> > On Mon, 2014-09-22 at 16:19 +0100, George Dunlap wrote:
> > > On 09/22/2014 02:56 PM, Ian Campbell wrote:
> > > > On Sat, 2014-09-20 at 14:07 -0400, Don Slutz wrote:
> > > >
> > > > > I picked this subset to start with because it only has changes in
> > > > > Xen.
> > > > >
> > > > > Some of this code is already in QEMU
> > > > As I suggest in my reply to one for the rpc port patches it's not clear
> > > > that any of this needs to be in Xen rather than qemu in the first place.
> > > >
> > > > I came to think this even more once I saw the save/restore support...
> > > I don't think qemu can get notified on either cpuid or #GP faults, can it?
> > I understand the need for the cpuid bits, I should have made that clear.
> >
> > > A big chunk of the functionality here is to allow a userspace process to
> > > transparently make the "hypercalls" without the OS needing to explicitly
> > > give it access to the IO space, by trapping the resulting #GP faults and
> > > checking to see if they are IO instructions .  If that's functionality
> > > we think is important, then it will have to be done in Xen, I think.
> > Ah, the need to #GP was what I had missed, I was thinking it was just a
> > regular I/O port access.
> >
> > Having trapped the #GP and decoded it into an IO access, is there
> > anything stopping us forwarding that to qemu for consideration?
> >
> > (I confess I'm not sure why this is a #GP thing and not a VTd/SVM I/O
> > access trap, just like if userspace mmaps /dev/ioports, but I'll trust
> > that's just my lack of x86 hw virt knowledge)
> I am fairly sure (reading the VMX/SVM manuals) that Xen can force a trap
> of a specific IO port as an IO access trap even if it would otherwise
> cause a #GP fault due to lack of IO permissions (which I guess is
> exactly for purposes like this).
Please direct me to this.  I see things like:

24593âRev. 3.18âMay 2011

15.10.2 IN and OUT Behavior
If the IOIO_PROT intercept bit is set, the IOPM controls port access. 
For IN/OUT instructions that
access more than a single byte, the permission bits for all bytes are 
checked; if any bit is set to 1, the
I/O operation is intercepted.


Exceptions related to virtual x86 mode, IOPL, or the TSS-bitmap are 
checked before the SVM
intercept check. All other exceptions are checked after the SVM 
intercept check.
I/O Intercept Information. When an IOIO intercept triggers, the 
following information (describing
the intercepted operation in order to facilitate emulation) is saved in 
the VMCBâs EXITINFO1 field:

This to me says that IOPL (aka generate a #GP) is checked before the SVM 
check.
    -Don Slutz

> I am also entirely certain that this is a far better position to be in
> than fully enabling #GP intercepts, assuming I have interpreted the
> manuals correctly.
>
> ~Andrew

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