From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH for-4.5 v6 00/16] Xen VMware tools support Date: Mon, 22 Sep 2014 16:52:39 +0100 Message-ID: <542045C7.3010100@citrix.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1411400048.26552.10.camel@kazak.uk.xensource.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: Ian Campbell , George Dunlap 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 , Boris Ostrovsky , Suravee Suthikulpanit List-Id: xen-devel@lists.xenproject.org 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). 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