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

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 09/22/14 11:55, George Dunlap wrote:
> 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.
Yes, this is why the port in question is (via vmport_register and 
register_portio_handler) is added
to the hypervisor ports that get handled by hypervisor code.

> > > Again, that's my understanding, someone please correct me if I'm 
> > > wrong...
Looks like a good statement, should I add it to a commit message?

> > It sounds plausible, for sure.
> >
> > Even so, why can't the result of that #GP be a calldown into qemu for
> > further processing?
This is not simple in that QEMU does not have access to the VCPU 
registers.  Unlike a normal
I/O request, vmware_port (aka vmport) both reads and writes VCPU registers.

> 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.
Clearly it is possible to pass the VCPU registers to QEMU, but that is 
currently not done.  So a new
version of QEMU would also be needed to go this way.  None the the 
proposed features need
any data from QEMU, so I do not think this make sense.

   -Don Slutz

>  -George

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