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

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>, Kevin Tian <kevin.tian@intel.com>,
	Keir Fraser <keir@xen.org>, Jun Nakajima <jun.nakajima@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Eddie Dong <eddie.dong@intel.com>, Don Slutz <dslutz@verizon.com>,
	xen-devel@lists.xen.org,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH for-4.5 v6 00/16] Xen VMware tools support
Date: Mon, 22 Sep 2014 16:52:39 +0100	[thread overview]
Message-ID: <542045C7.3010100@citrix.com> (raw)
In-Reply-To: <1411400048.26552.10.camel@kazak.uk.xensource.com>

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