[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] IO emulation for HVM guest.



 

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Praveen Kushwaha
> Sent: 04 April 2007 11:03
> To: xense-devel-request@xxxxxxxxxxxxxxxxxxx; 
> xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] IO emulation for HVM guest.
> 
> Hi,
> 
>            Since the for HVM guest(full virtualization) , the 
> emulated version of the all the IO devices are resides in dom0.

Correct at the time of writing. There are discussions to move this into
a "stub-domain", but that doesn't change any of the following discussion
- it changes the internals of QEMU-DM, but that's not really important
here.
> 
>            Whenever HVM guest needs to access IO, VMExit 
> happens(transition from guest to VMM). And from the VMM 
> request goes to dom0, where emulated version of the IO device 
> serves the request. 

Yes, that's how it works.
> 
>  
> 
> 1. So the my question is that I want to put some hooks in the 
> dom0, to capture the request. Is it possible to put hooks in 
> dom0 for IO request from HVM guest?  

Yes, it would be possible to put a device-hook somewhere in QEMU (but
there's no pre-defined hooks, you'll have to add that to QEMU). 

If you want to prevent guest from at all accessing the hard-disk (but
WHY would you want this - you may just as well not give it access in the
first place - dom0 is still in control of what domains get started and
what the contents of the configuration file is, right?) you could easily
do that. Similarly with all other IO-devices. 

If you want to prevent the guest from writing to c:/windows/system32
you're much better off putting file-system driver inside Windows (aka.
Anti-virus software etc.). This is because QEMU doesn't actually know
what part of the hard-disk contains what, and has no idea if the file
being accessed is in /windows/system32/win32.dll or /temp/blah.txt -
just that it happens to be sector 432611 on hard-disk 0. 

> 
> 2. As per my knowledge there is qemu-dm which provides the 
> emulated version of IO devices. Therefore What exactly the 
> code I should look in xen for qemu-dm which handles the IO request?

You'll find the ide-driver in .../tools/ioemu/hw/ide.c, parallel port is
in same location, parallel.c, sieral port in serial.c, etc, etc. 

At a higher level, you can capture all IO requests at
.../tools/ioemu/target-i386-dm/helper2.c, which is done in
cpu_handle_ioreq(), and the corresponding code in the hypervisor lives
in .../xen/arch/x86/hvm/platform.c: send_{p,mm}io_req functions.

> 
> 3. what is the role of device channels in communication of IO 
> from HVM guest?

If by "device-channel" you mean the combination of a shared-memory area
and a event-channel, then yes, there is an IOREQUEST data structure
which is shared between QEMU and the hypervisor [but not accessible by
the guest itself]. 

If you mean in some other aspect of the "device channel", I believe the
answer is "no". 

And I still don't see how you can achieve anything valuable or useful by
intercepting this IO operations at this level (at least not for
relatively complex devices such as hard-disk controllers or network
controllers - preventing access to the serial port maybe possible (or
even filtering the output to the serial port), but the meaning of
individual blocks to the hard-disk is pretty difficult to reverse
engineer to understand what they belong to, you need a higher level
intercept for that [and Xen doesn't allow for that in either
Para-virtual or fully virtualized domains].

--
Mats
> 
>  
> 
>  
> 
> Thanks,
> 
> Praveen Kushwaha
> 
>                                     
> 
>  
> 
>  
> 
> 



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.