RE: Device model architecture (Was Re: [Xen-devel] Re: Arelinkerscripts needed?)

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Ian Pratt
>Sent: Friday, May 27, 2005 6:49 PM
>> I guess the main logic behind your argument is that there is
>> no need to fully virtualize the device models, so no need to
>> run them within a non-root VMCS.
>
>We can't run them in the same non-root VMCS as the guest since we need
>some virtual address space. Since the hardware does a cr3 switch to the
>monitor_table when doing a vmexit, wwe might as well make better use of
>this and treat the device models as just another paravirtualized guest.

The major benefit of running in vmx mode is the clean and easy support
to existing distribution, without compilation and modification.
Regarding the device model proposed in this thread, since major
modification is unavoidable to add frontend-backend interfaces, I'm also
inclined to take it as another paravirtualized guest as Ian said, to get
maximum performance ;-) 

Actually there're few chances for such standalone DM to access privilege
resources like normal OS kernel. The only event it needs to care
frequently is the notification for emulation start and the one for
completion from backend, and then the only handler can be easily
optimized to cooperatively access necessary context passed from HV. Most
privilege setting can be completed in batch when starting the DM, and
then stable in almost whole lifecycle.

>
>> The only comment I have is: for the case where the device
>> models require the services of a backend driver, you might be
>> paying more than what we currently pay (one domain switch)
>> i.e. vmx domain -> mini os -> backend. But it should be
>> faster for everything else.
>
>The vmx_domain to mini-OS switch happens as part of the vmexit. Work
>will get queued just like a normal frontend talking to a backend, so I
>don't think there's a performance issue here -- it will certainly be
>faster than the current situation.

if I understand correctly, current model does only issue one domain
switch, but it needs more kernel/user context switches which depends on
how many system call issues and how many processes running in service
OS. With DM on mini-OS, one extra context switch does happen between
monitor and mini-OS. But then frontend of DM talks to backend in service
OS directly, and the later resides in kernel space. So actually mini-OS
approach should be faster... and current approach is easier for
maintain. ;-)

>
>Devices such as the APIC/IOAPIC/PIT etc can all be emulated without
>calling out of the device model, and should work with just the same
>performance as having them in Xen as we do today.

Agree.

Thanks,
Kevin

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