RE: [Xen-devel] Communication between HVM and dom0 through the Hypervisor

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: M.A. Williamson [mailto:maw48@xxxxxxxxxxxxxxxx] On 
> Behalf Of Mark Williamson
> Sent: 19 April 2007 03:22
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Petersson, Mats; Daniele Sgandurra
> Subject: Re: [Xen-devel] Communication between HVM and dom0 
> through the Hypervisor
> 
> > > Is there currently a method for passing information
> > > between a HVM domain and domain 0 directly through the
> > > hypervisor?
> > > I understand there could be at least three ways to do
> > > so:
> > >
> > > -VMCALL from HVM + params in registers.
> > > -using "PV-on-HVM", but I think the frontend drivers
> > > need to be ported in the mainline Linux kernel and
> > > this is currently being done, right?
> >
> > What do you mean. There is the "unmodified_drivers" 
> directory in Xen,
> > which contains, as far as I know, complete drivers for 
> block and network
> > on HVM Linux. Of course, you'd need a differnet source-code 
> if you want
> > Linux 2.4 drivers or Windows drivers, neither of which is 
> supplied with
> > Xen's sources.
> 
> I think Daniele has read confusing accounts of the PV-on-HVM 
> drivers vs the 
> mainline kernel merge.  These are (semi) independent issues: 
> for Linux 2.6 
> PV-on-HVM drivers can simply be built by the administrator 
> and installed into 
> their VM if they want them.
> 
> The code that's being proposed for the Linux merge is to 
> support full PV, not 
> PV-on-HVM (as far as I know).
> 
> > > -using XenStore/XenBus (is that possible?)
> >
> > I believe so, but I'm not entirely sure about how that 
> works in a HVM
> > guest.
> 
> Yes, but it requires the PV-on-HVM driver infrastructure.  
> I'm not clear on 
> the exact implementation details, but it involves the guest 
> talking to a 
> fake "Xen platform" PCI device, which enables it to then set 
> up a Xenstore 
> connection and share configuration data on it.

Thanks for filling that in. 
> 
> > > As an example, suppose I have a HVM running Linux (on
> > > Intel IVT-x), and I want to call a callback function
> > > in dom0 each time the HVM contacts the hypervisor,
> > > what would you suggest me to do? Imagine I want to
> > > notify dom0 each time a process issues a system call,
> > > by adding some code in the prologue of the syscall
> > > handler to notify the hypervisor.
> >
> > You can use VM[M]CALL, although this is ALREADY being used 
> for PV-on-HVM
> > drivers, so you'd have to filter your calls from the ones used by
> > PV-on-HVM drivers (using a high bit to indicate that those are your
> > functions rather than PV-calls would be the easiest method).
> >
> > Another possibility is to find a unused IO-port or memory 
> address and
> > cause a IOIO-exit or Page-fault on a MMIO address that 
> isn't otherwise
> > used. IO-ports such as 0xBCDE, 0xAAA0 are most likely not 
> used, so you
> > could to a 8, 16 or 32-bit IO to one of those pretty easily.

One thing I forgot to add: At the point of the intercept, you will have
access to all CPU registers, so it's not really important which method
you use for the intercept from that perspective.
> >
> > The NEXT problem is of course getting this information out of the
> > hypervisor into Dom0.
> 
> It it possible to arrange for a VMEXIT to occur on int 0x80 
> (which IIRC is the 
> Linux system call...  I guess VT-x would also be able to 
> intercept sysenter)?  
> That way the guest wouldn't have to be modified to notify 
> Xen.  Xen would 
> then have to e.g. share a ring buffer with dom0 regarding 
> events of this 
> nature for each domain.  You could hack something up so that 
> the guest 
> blocked on each syscall until dom0 acknowledged it...

Now,that's a brilliant idea. Why didn't I think of that. 

Only one minor problem: It will only work for INT n instructions (but
since it's possible to hide SYSENTER/SYSCALL instrutions from the guest
via CPUID intercept, it can at least for 32-bit be forced to only do INT
80h calls), and only on AMD processors (this is more of a problem, as
the original post talks about Intel processors). Intel processors don't
allow intercepts of INT n instructions. Neither processor allow
intercepts of SYSENTER/SYSCALL instructions. [It's still a very good
idea, and I wish I had at least THOUGHT of it!]

--
Mats

> 
> There's also the Xen gdb server - maybe (if it supports HVM 
> guests?) you could 
> use this to watch the syscall paths.
> 
> HTH,
> cheers,
> Mark
> 
> -- 
> Dave: Just a question. What use is a unicyle with no seat?  
> And no pedals!
> Mark: To answer a question with a question: What use is a skateboard?
> Dave: Skateboards have wheels.
> Mark: My wheel has a wheel!
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel