Re: [Xen-devel] [PATCH v3 04/16] hypervisor part of add vmware_port to xl.cfg

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 09/08/14 11:43, Boris Ostrovsky wrote:
> On 09/08/2014 11:32 AM, Andrew Cooper wrote:
> > On 08/09/14 16:22, Jan Beulich wrote:
> > > > > > On 08.09.14 at 17:01, <boris.ostrovsky@xxxxxxxxxx> wrote:
> > > > I wonder whether we should enable #GP intercepts only when we know 
> > > > that
> > > > the guest is VMware-aware (which we do as far as I can tell since we
> > > > have a config option).
> > > I didn't look at the patches themselves yes, but I very much expected
> > > this to now be the case considering discussion on the earlier version.
> > > If it's not, I'm not even sure looking at the new version is going 
> > > to be
> > > of much use...
Getting the adjustment of #GP exits at the time of setting of hvm param
vmware_port to 1 is more complex.  But I do think that the allowing it
to be deferred until the next #VMEXIT would work just fine.

I will see how well that works.

> > > Jan
> > I find it incredibly hard to believe that VMWare do unconditional #GP
> > exits, and looking at the Intel manual, you do not actually need to
> > intercept #GP faults.
> >
> > The "unconditional I/O exiting" control can be used to cherry-pick
> > specific IO ports in combination with the IO port bitmap, ahead of the
> > #GP fault due to a failure of IOPL.  I would expect AMD has a similar
> > option.
> Yes, it does. However, I believe #GP intercept has been added so that 
> IO access can be made from guest's ring 3 as well, not to handle IO 
> access in general.
> Having said that, I don't remember seeing updates to IO permissions 
> map in the patch.
There are no updates to IO permissions map.  My understanding that it
controls access to real hardware, not that it changes the IOPL checking
in the in instruction.

Here is what I am looking at:


  This control determines whether executions of I/O
  instructions (IN, INS/INSB/INSW/INSD, OUT, and
  OUTS/OUTSB/OUTSW/OUTSD) cause VM exits.


Which to me is about #VMEXIT or access host hardware, not
"Change a #GP into a #VMEXIT for this port."

The goal is to get #VMEXITs when needed, not to allow domU to access
a VMware running Xen under it.

For the non-#GP case (domU ring 0 access to the port), it is handled
by register_portio_handler() which would adjust the IO permissions map
as needed.


    -Don Slutz

> -boris

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