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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 09/22/2014 04:50 PM, Ian Campbell wrote:
> On Mon, 2014-09-22 at 16:38 +0100, George Dunlap wrote:
> > On 09/22/2014 04:34 PM, 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'm not 100% sure of this, but my understanding was that it *would* be a
> > normal IO trap *if* the guest OS gave access to that IO range to the
> > guest (via IOPL, maybe?).  But if the userspace program is not
> > explicitly given access by the OS to those ports, it will generate a #GP
> > instead.  The idea is to allow the "hypercall" to happen *without
> > cooperation* from the guest OS.
> >
> > Again, that's my understanding, someone please correct me if I'm wrong...
> It sounds plausible, for sure.
>
> Even so, why can't the result of that #GP be a calldown into qemu for
> further processing?
I was only responding to the part of your comment in parentheses. :-)

I suppose in large part it would depend on what the hypercalls were 
actually doing; I'd have to go back and look at them to say if they need 
to be in Xen or whether they could be passed on to qemu.
 -George

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