From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH for-4.5 v6 00/16] Xen VMware tools support Date: Mon, 22 Sep 2014 13:19:25 -0400 Message-ID: <54205A1D.90700@terremark.com> References: <1411236447-7435-1-git-send-email-dslutz@verizon.com> <1411394209.18331.113.camel@kazak.uk.xensource.com> <54203DE9.9040307@eu.citrix.com> <1411400048.26552.10.camel@kazak.uk.xensource.com> <54204280.2030408@eu.citrix.com> <1411401014.26552.15.camel@kazak.uk.xensource.com> <54204657.5080906@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54204657.5080906@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Ian Campbell Cc: Tim Deegan , Kevin Tian , Keir Fraser , Jun Nakajima , Stefano Stabellini , Ian Jackson , Eddie Dong , Don Slutz , xen-devel@lists.xen.org, Aravind Gopalakrishnan , Jan Beulich , Andrew Cooper , Boris Ostrovsky , Suravee Suthikulpanit List-Id: xen-devel@lists.xenproject.org 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