> > 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.
> > 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.
>
> 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...
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
|
Home