[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |