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