WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Praveen Kushwaha" <praveen.kushwaha@xxxxxxxxxxx>, xense-devel-request@xxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] IO emulation for HVM guest.
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Wed, 4 Apr 2007 12:57:08 +0200
Delivery-date: Wed, 04 Apr 2007 03:56:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <0A8CFEC45B7F4C419F7543867C47442384847E@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acd2oHUb1lbi27Z7SAaJxwIpD3EceAAAu64w
Thread-topic: [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

<Prev in Thread] Current Thread [Next in Thread>