December 25th, 2012

Virtualbox – Host guest communication.

Will try to explain the architecture/design behind host guest communication in VBox with an example of display.

You can dynamically configure virtual monitors (attached to guest OS) using SetVideoModeHint command from the host. This involves transfer of parameters from host to guest and vice versa.  So, I will take this as the basis to explain the communication part.

Following layers are involved int he communication:

On HOST Side

1) App Layer

2) VMM driver (a virtual PCI device)

On Guest Side

1) VBoxClient on Linux nad VBoxTray on Windows – User mode app

2) VBoxGuest driver

Roles of each layer.

App layer on the HOST side: is responsible for sending the request to the guest to perform the desired action. In our case App layer represents SetVideoModeHint API.

VMM layer on the HOST: catches the request send from the app on the host side. Corresponding to request from the app, it issues an IRQ to the guest. It acts as a medium for communication between host and guest.

VMM layer is represented as a PCI device . The guest sends messages to the host using device I/O on the VMM device, and the host alerts the guest that it wants to send a message using IRQs, whereupon the guest queries the host for the message via device I/O .

The communication takes place via more-or-less fixed format messages (VMM device requests) which are more or less the bottom layer of the communication stack.

The host (VMMDev) sends VMM device event to the guest.  It does that by sending an IRQ, and the guest’s IRQ handler (VBoxGuest driver) immediately queries the event code/number.  It then notifies any guest process (kernel or user space- Guest side app, VBoxClient or VBoxTray) which is listening for that event number, and that process usually sends a device request to the host to retrieve more information relating to the request.

GUEST Side App: Acts as a listener and continuously polls the guest side VMM driver (VBoxGuest driver) for any events.

GUEST side VMM Driver (VBoxGuest Driver) –   the guest VMMDev driver receives the IRQ it checks the event bitmask. and report events to the listeners. Listeners may request additional information about the event from the host using VMMDevReq_* requests.

 

Thanks

Anshul Makkar

mailto: anshul_makkar@justkernel.com

CategoryVirtualization | CommentNo Comments »

Tags:
November 7th, 2012

SYSTEM & Device Power State Handler (Ref to USB)

Recently worked on the issue where in the system was not able to hibernate or sleep properly when a USB device is attached to it (Ofcourse its just a jist of the issue , but can’t disclose the actual scenario) . So had a chance to understand the power implementation in the WDM driver.

I had my custom USB function driver installed that also acted as a power policy owner for the device.

As per the MS docs (Refs)

http://msdn.microsoft.com/en-us/library/windows/hardware/ff559734%28v=vs.85%29.aspx

http://msdn.microsoft.com/en-us/library/windows/hardware/ff559734%28v=vs.85%29.aspx

http://msdn.microsoft.com/en-us/library/windows/hardware/ff559734%28v=vs.85%29.aspx

(Note: Here if driver will mean the Functional driver for the attached USB device that also acts as a power policy owner for the device)

The  driver (Power Policy owner driver) needs to handle the device power in response to the SYSTEM irps (IRP_MN_QUERY_POWER or IRP_MN_SET_POWER) that it receives. In the handler routines for the above irps , the driver should send the corresponding irps for the attached child device.

A device power policy owner calls PoRequestPowerIrp to send a device query- or set-power IRP when it receives a system query- or set-power IRP.

In response to the call to PoRequestPowerIrp, the power manager allocates a power IRP and sends it to the top of the device stack for the device. The power manager returns a pointer to the allocated IRP.

Thus keep in mind, during the handling of the Device Power IRP , two requests are pending – One for the System Power IRP and One for the Device Power IRP.

Sample Code.

static NTSTATUS SystemPowerStateHandler(pDevExt, IN PIRP pIrp)
{
PIO_STACK_LOCATION pSl = IoGetCurrentIrpStackLocation(pIrp);
SYSTEM_POWER_STATE enmSysPState = pSl->Parameters.Power.State.SystemState;
IoMarkIrpPending(pIrp);
IoCopyCurrentIrpStackLocationToNext(pIrp);
oSetCompletionRoutine(pIrp, SystemPowerComletionRoutine, pDevExt, TRUE, TRUE, TRUE);
NTSTATUS Status = PoCallDriver(pDevExt->pLowerDO, pIrp);
/* Sending Device Power state change or query request in response for the 
SYSTEM level request */
Status = PoRequestPowerIrp(pDevExt->pPDO, pSl->MinorFunction, PwrState,
                        DevicePowerCompletionRoutine, pDevCtx, NULL);
}

CategoryWindows Kernel | CommentNo Comments »

October 11th, 2012

Virtualbox – Saving and retrieving Disk Details from CMOS

Virtualbox saves the geometry information for the SATA disk in the CMOS which is then retrieved by BIOS.

CMOS offset is calculated in the DevPcBios.cpp and is based on the disks attached. for eg if there is 1 disk attached the disk geometry information is saved in CMOS at offset 0×40, if two disks are attached the for the first information will be available at 0×40 and for second 0×48. (For details please refer DevpcBios.cpp CMOS Assignment section).

Calculation process:

DevPcBios.cpp queries the CFGM keys like SataPrimaryMasterLUN and based on this LUN value is extracted. Now this extracted LUN value serves as the basis for the calculation of CMOS offset for saving SATA disk info e.g
switch(i)
{
case0:
offInfo = 0×40;
case 1:
offInfo = 0×48;
-
case 3:
offInfo = 0×58
}.

BIOS then applies similar logic to calculate the offset value to read the geometry information from CMOS. The logic for this is in ahci.c.

Thanks

Anshul makkar

For query please mail: anshul_makkar@justkernel.com

 

CategoryUncategorized | CommentNo Comments »

« Older Entries