[vbox-dev] Using HGCM

[Michael Thayer]

Hello Nev,

Le jeudi 04 mars 2010 à 19:57 +1100, Nev a écrit :
> My apologies for my late response, but I have had an email system
> failure.
Apologies for mine.  I was trying to think of something brilliant to
answer, failed, and then got distracted by other things.


> But your responses has caused me to re-address my approach, as the use
> of HGCM was going to be an attempt to get a shared memory block between
> the Guest OS and the Host OS. If I need to use the OSE then I think a
> more direct interface may be more appropriate.
As I can't think of some other brilliant solution, I would agree with
this.  I'm not fully clear though about what you need.  Do you need to
map a random block of host memory to the guest?  Or is it enough to be
able to share any block of host memory?  I wonder whether creating a
simple virtual PCI device with a block of PCI memory and making that
into a shared memory area on the host side would do what you need?

> I suspect that the current implementation of HGCM maps Guest PCI device
> memory into the Host's memory space. This is not ideal for my
> application.
HGCM reads directly from guest memory, since of course all guest memory
is also host memory.  However this is done by the HGCM infrastructure
code, not by the services themselves - they provide buffers into which
data is copied.

> Ideally I would like to be able to map Host's memory into the Guest's
> address space. This would mean that only the Guest's PR_XXXXSharedMemory
> functions should need to change, maybe with a flag used to request Host
> sharing or not.
> 
> Each Guest function would somehow need to pass each call to the Host's
> matching function, maybe via HGCM.
> 
> The performance of these function should not be overly important, as
> long as the resulting shared memory can be read and written from both
> the host and guest application code without generating exceptions,
> except for the normal exceptions all memory is subjected to.
> 
> So now some questions:
> 1. Does this approach seems reasonable and doable?
> 2. Is anyone else working on a shared memory interface?
> 3. Is there any possibility of having this interface (provided it works)
> including into the OSE? and also included into the closed source
> product?
To 2) and 3) - not that I am aware of, and we are always interested in
useful contributions.

> I can see a number of reasons NOT to including a shared memory interface
> 1. Decreased separation between Guest and Host, which of cause is the
> purpose of Shared memory.
If the feature can be enabled or disabled for a given VM, then from our
point of view this is the VM owner's business.

> 2. Decreased security. Provided the shared memory is NOT executable, I
> don't think this is a major issue, but not all hardware/OS can protect
> memory region from execution.
> 3. Unable to live migrate Guest to another host while a shared memory
> block is open. Also Snap shots would be difficult or impossible with
> shared memory blocks open.
Since as far as I remember a VM is basically saved and the VM
application on the host shut down when it is migrated, this just means
that your host code has to behave correctly during saving and shutdown,
which is a basic requirement for all code in VirtualBox.  If you create
a virtual PCI device, this would be handled in the device and host-side
"driver" code.

Regards,

Michael
-- 
Sun Microsystems GmbH        Michael Thayer
Werkstrasse 24               VirtualBox engineer
71384 Weinstadt, Germany     mailto:michael.thayer at sun.com

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels
Vorsitzender des Aufsichtsrates: Martin Haering