Xen devel - May 2005 - Device model architecture (Was Re: Re: Are linker scripts needed?)

Ian Pratt wrote:
> I''d be inclined to move to a model where we execute the device
emulation
> in the root (monitor) VMCS, using the same protection mechanism we use
> for para-virtualized guests e.g. segmentation for x86, paging for
> x86_64. The device emulation should should work like a normal front-end
> driver, connecting via a device channel to a normal backend.
> 
It sounded like you were proposing linking the device models against 
Xen. But your subsequent messages appear to say:

- For every VMX domain created, create a new helper domain
- The helper domain shares it''s page list with the VMX domain
- xen is protected from the helper domain using paging/segmentation
- helper domain runs minios
- Use the existing mechanisms (backend drivers) to get storage/network 
services from dom0

Did I get it right? If yes,

- why is this better than running the device models inside the VMX 
domain? Do you expect switching to the helper domain to be faster than a 
  vmx world switch?
- what''s the advantage of running minios vs xenolinux in the helper
domain?

I think we all agree that:

- It''d be good to make the device models "embeddable" so that
it could
be moved closer to the domain it''s servicing. This is where the bulk of
the work is, regardless of which model we end up choosing.

- Make sure that there is a unified way to manage the resources given to 
the VMX domain (including the device models)

	-Arun

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

On 24 May 2005, at 19:28, Arun Sharma wrote:
> Ian Pratt wrote:
>> I''d be inclined to move to a model where we execute the device
>> emulation
>> in the root (monitor) VMCS, using the same protection mechanism we use
>> for para-virtualized guests e.g. segmentation for x86, paging for
>> x86_64. The device emulation should should work like a normal 
>> front-end
>> driver, connecting via a device channel to a normal backend.
>
> It sounded like you were proposing linking the device models against 
> Xen.
No, Ian is suggesting running them in ''paravirtualised mode'':
probably
in ring 3 of the root VMCS. So there will be three contexts that a VMCS 
domain runs:
  1. Full-virt context (guest VMCS, rings 0-3)
  2. Hypervisor context (root VMS, ring 0)
  3. Paravirt driver context (root VMCS, rings 1-3)
> - For every VMX domain created, create a new helper domain
> - The helper domain shares it''s page list with the VMX domain
> - xen is protected from the helper domain using paging/segmentation
> - helper domain runs minios
> - Use the existing mechanisms (backend drivers) to get storage/network 
> services from dom0
Yes.
> - why is this better than running the device models inside the VMX 
> domain? Do you expect switching to the helper domain to be faster than 
> a  vmx world switch?
Depends on whether you can make the CPU do a direct switch, or if you 
need to ''bounce'' through root VMCS (taking an extra cr3
switch).
> - what''s the advantage of running minios vs xenolinux in the
helper
> domain?
Full xenolinux is totally unnecessary. We just want enough support 
services to run the device emulator and front-end driver stub. We''re 
best building those from scratch -- it''ll look nothing like an 
operating system.
> I think we all agree that:
>
> - It''d be good to make the device models "embeddable" so
that it could
> be moved closer to the domain it''s servicing. This is where the
bulk
> of the work is, regardless of which model we end up choosing.
>
> - Make sure that there is a unified way to manage the resources given 
> to the VMX domain (including the device models)
Yes, agreed.

  -- Keir


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