Re: Xen as a kernel module

[Jacob Gorm Hansen <jacobg@diku.dk>]

Steven Hand wrote:

> Maybe - I guess it depends on what you mean. If you have: 
> 
>      [ VM1 ]   [ VM2 ] ....   [ VMN ] 
> 
>       [ new type II version of Xen ] 
> 
>             [ linux kernel ] 
> 
>               [ hardware ]

Sorry if this came out sounding as a bit of a troll, anyway, my 
suggested setup would look like this:

       [ VM1 ]   [ VM2 ] ....   [ VMN ]

           [ Xen + linux kernel ]

                [ hardware ]


> then you require a way for VMx to communicate the new Xen thing, 
> which then needs to syscall into the linux kernel. I'm not sure 
> what VMx<->Xen comms would look like, or how it would perform. If
> you retain safety it seems like you might end up with the performance
> of UML, which if you go for 'high performance' then you may need to 
> turn off the safety catch. 

Right now Xen is mapped somewhere in top of memory, I am not sure how 
domains are kept out of there, but I suppose it has to do with segments. 
The good thing about that is that hypercalls are cheap, and in Xen1.x 
I/O was cheap as well.

My suggestion/question was a) why don't we just put a full Linux up 
there, including drivers, and b) can we provide the Xen hypercall 
interface on top of other OSes as well?

> How did you see this working? 

For Linux, I would relocate it to the top X megs of memory, and I would 
merge the Xen and Linux syscall handlers, essentially supporting two 
process models under the same OS. I would not map all of memory to 
Linux, just the pages it needs for its own stuff. For a driver OS, this 
would be fine, if you want to run applications as well there would be a 
tradeoff between how much you map to Linux and how much to Xen domains.

> What aspects of performance under Xen are you finding unacceptable? 

I generally find performance acceptable, but as I said there are cases 
where there appears to be some friction against the goals of Xen (driver 
isolation) and the goals of the application (throughput, low latency).

> Well isolation (both security and performance) are two explicit 
> design goals of Xen. If you want to have the illusion of multiple
> kernels without these properties, you can use linux vservers or 
> BSD jail. 

I would argue that you could get the same level of isolation (except 
from driver isolation) if you merge the two, while achieving the same IO 
performance as the monolithic model, and still be able to reuse existing 
driver code.

>>I imagine this could be done in a way that would also work under other 
>>host-OSes, like *BSD or Windows.
> 
> 
> Again, I'm not sure how much code-base similarity there would be with
> either current Xen or the type-II variant that you propose above. 

It would still be interesting to reuse existing Xen guestOS ports on top 
of different hypervisor implementations.

Jacob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl