(Just some rough idea, since I don't know much detail of DM part. ;-)
>I suppose it improves performance and simplifies the data path, but it
>should probably dynamically map the vmx guest's pages for I/O on
>demand. After all, this approach isn't going to work for bigmem domains
>on i386 (particularly once PAE is working). So it seems a bad idea to
>come to rely on it any more than as a bit of a hack to get you up and
>running.
Another requirement for dynamic map on demand is that guest pfn ->
machine pfn mapping may be changed due to balloon driver. It's not that
perfect for a DM to assume that mapping info never changed, and thus
maps all the guest memory in one request at the start...
>
>Best of all (imo) would be for it to act as a 'driver in the middle':
>connecting the fully virt guest through to an ordinary backend driver,
>and not itself touching I/O buffers at all. Perhaps ultimately we can
>push the qemu drivers into the vmx container itself, perhaps in
>'virtual smm mode', so that from outside the container it looks just
>like any other paravirt I/O channel.
>
Frist, to clarify a term: Do you mean vmx container as "vmx domain" ? :)
Major benefit of your approach, from my thought, is that backend driver
in service OS can service both para-virtualization and
full-firtualization domain then, with a unified channel interface and
logic, right? I'm trying to understand how 'virtual smm mode' you
mentioned can be achieved, and thinking at least following modifications
may be required:
- DM can not only be user application. A bunch of kernel module
like a collection of existing frontend drivers have to be created for
each component of DM in vmx container.
- DM itself has to be bound with a faked device (Maybe PCI
device), to be able to receive emulation message coming from HV, after
HV captures unmodified domain's access to MMIO, etc.
- More backend-frontend drivers need time to be cultivated
gradually, like SCSI support, etc, to behave like a complete DM.s
However the major defect somehow may lie with the maintain effort. Also
take USB port as the example, there'll be around 10 or more maintainers
of different backend-frontend components, who have to keep up with
kernel evolvement both on service OS side and domainN side, since kernel
module is tightly coupled with kernel internal interfaces. However
current DM model has no such problem. With more deployment of xen,
there'll be more such effort. Of course, also with more deployment of
xen, there'll be more people who'd like to contribute to xen then. ;-)
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home