Status of ioemu code in unstable?

Status of ioemu code in unstable?

[John Byrne]

Hi,

I've been trying to find out from the xen-devel archives and Google and 
I cannot seem to find the information I'm looking for.

I assume the goal of the ioemu is to provide necessary support for 
non-paravirtualized guess running on VT-x hardware. At a minimum I'd 
guess you'd need BIOS emulation, display card emulation, and timer/ 
interrupt emulation.

I'd like to know what's there; what works; and what else might be 
needed. A pointer to the information or a summary would be appreciated. 
Also, there is one item in the todo list in the wiki that suggests that 
the ioemu code will all be re-written. Is this for performance reasons?

Thanks,

John Byrne

Re: Status of ioemu code in unstable?

[Arun Sharma]

John Byrne wrote:
> 
> Hi,
> 
> I've been trying to find out from the xen-devel archives and Google and 
> I cannot seem to find the information I'm looking for.
> 
> I assume the goal of the ioemu is to provide necessary support for 
> non-paravirtualized guess running on VT-x hardware. At a minimum I'd 
> guess you'd need BIOS emulation, display card emulation, and timer/ 
> interrupt emulation.

See foil 10 of:

http://summit.xensource.com/pdfs/Xen_VT_Status_TODO_Intel_ASharma_EtAl.pdf

for a summary of what's working.

Since then, we've added support for BIOS emulation (tools/firmware).
The current device models are based on qemu-0.6.1.

> I'd like to know what's there; what works; and what else might be 
> needed. A pointer to the information or a summary would be appreciated. 
> Also, there is one item in the todo list in the wiki that suggests that 
> the ioemu code will all be re-written. Is this for performance reasons?

Yes, switching to dom0 for every I/O request is very expensive. But that 
was the easiest and cleanest initial implementation.

We've also accelerated the PIT by moving it into the hypervisor and have 
patches for implementing the local APIC support in xen.

	-Arun

Re: Status of ioemu code in unstable?

[John Byrne]

Arun Sharma wrote:
> John Byrne wrote:
> 
>>
>> Hi,
>>
>> I've been trying to find out from the xen-devel archives and Google 
>> and I cannot seem to find the information I'm looking for.
>>
>> I assume the goal of the ioemu is to provide necessary support for 
>> non-paravirtualized guess running on VT-x hardware. At a minimum I'd 
>> guess you'd need BIOS emulation, display card emulation, and timer/ 
>> interrupt emulation.
> 
> 
> See foil 10 of:
> 
> http://summit.xensource.com/pdfs/Xen_VT_Status_TODO_Intel_ASharma_EtAl.pdf
> 
> for a summary of what's working.
> 
> Since then, we've added support for BIOS emulation (tools/firmware).
> The current device models are based on qemu-0.6.1.
> 
>> I'd like to know what's there; what works; and what else might be 
>> needed. A pointer to the information or a summary would be 
>> appreciated. Also, there is one item in the todo list in the wiki that 
>> suggests that the ioemu code will all be re-written. Is this for 
>> performance reasons?
> 
> 
> Yes, switching to dom0 for every I/O request is very expensive. But that 
> was the easiest and cleanest initial implementation.
> 
> We've also accelerated the PIT by moving it into the hypervisor and have 
> patches for implementing the local APIC support in xen.
> 
>     -Arun
> 
> 

Thanks.

Can any of this be tested with non-VT-x hardware?

There appears to be VNC support in qemu which I assume will allow you to 
see both the text and graphics (X) mode of the emulated console. If so, 
is there a way to achieve this with a para-virtualized kernel? My 
undertanding is that the xen changes to the Linux kernel include changes 
to the console driver to talk to the xen tools and that is you want and 
X server, you run Xvnc. So, looking at the text console and the X server 
require different tools.

If I were trying to manage virtual machines, I'd want a solution that 
didn't care about what kind of kernel I was running.

John Byrne

Re: Status of ioemu code in unstable?

[Arun Sharma]

John Byrne wrote:

> Thanks.
> 
> Can any of this be tested with non-VT-x hardware?
>

Yes, you can download a copy of qemu-0.6.1 and test most of the code 
(but not the VT-x specific code). But it won't solve your issue with 
para virtualized domains.

	-Arun

Re: Status of ioemu code in unstable?

[Anthony Liguori]

John Byrne wrote:

> There appears to be VNC support in qemu which I assume will allow you 
> to see both the text and graphics (X) mode of the emulated console. If 
> so, is there a way to achieve this with a para-virtualized kernel?

There is an item on the TODO list to implement a para-virtualized 
framebuffer.  That would provide this sort of functionality.  I don't 
know if anyone is actively working on it but I know there's at least 
been some discussion abou tit.

Regards,

Anthony Liguori

> My undertanding is that the xen changes to the Linux kernel include 
> changes to the console driver to talk to the xen tools and that is you 
> want and X server, you run Xvnc. So, looking at the text console and 
> the X server require different tools.
>
> If I were trying to manage virtual machines, I'd want a solution that 
> didn't care about what kind of kernel I was running.
>
> John Byrne
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: Status of ioemu code in unstable?

[John Byrne]

Anthony Liguori wrote:
> John Byrne wrote:
> 
>> There appears to be VNC support in qemu which I assume will allow you 
>> to see both the text and graphics (X) mode of the emulated console. If 
>> so, is there a way to achieve this with a para-virtualized kernel?
> 
> 
> There is an item on the TODO list to implement a para-virtualized 
> framebuffer.  That would provide this sort of functionality.  I don't 
> know if anyone is actively working on it but I know there's at least 
> been some discussion abou tit.
> 
> Regards,
> 
> Anthony Liguori


Thanks.

A few more questions. Does the VGA emulation require VT-x? (Qemu has 
been around for a while, so I suspect not.) Could the xen console 
changes be removed and a consistent model for the console be used? (I'd 
guess the console was done the way it was because something was needed 
and it was easiest to do it the way it is done, but is it necessary now 
that the emulation code is available?) If there is a requirement that 
the text mode console talk via a xen channel to the xen tools, can it be 
done in addition to the emulation?

John Byrne


> 
>> My undertanding is that the xen changes to the Linux kernel include 
>> changes to the console driver to talk to the xen tools and that is you 
>> want and X server, you run Xvnc. So, looking at the text console and 
>> the X server require different tools.
>>
>> If I were trying to manage virtual machines, I'd want a solution that 
>> didn't care about what kind of kernel I was running.
>>
>> John Byrne
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
> 
> 

Re: Status of ioemu code in unstable?

[Gerd Knorr]

John Byrne <john.l.byrne@hp.com> writes:

> A few more questions. Does the VGA emulation require VT-x?

Yes.

> Could the xen console changes be removed and a consistent model for
> the console be used?

Well, first we'll need a paravirtual framebuffer driver.  Shouldn't be
that hard, I did something simliar for UML some time ago.

I think a console terminal should better be mapped to a virtual serial
port than a linux virtual console, that tends to be work better.

  Gerd

Re: Status of ioemu code in unstable?

[Anthony Liguori]

John Byrne wrote:

>> There is an item on the TODO list to implement a para-virtualized 
>> framebuffer.  That would provide this sort of functionality.  I don't 
>> know if anyone is actively working on it but I know there's at least 
>> been some discussion abou tit.
>>
>> Regards,
>>
>> Anthony Liguori
>
>
>
> Thanks.
>
> A few more questions. Does the VGA emulation require VT-x? (Qemu has 
> been around for a while, so I suspect not.) Could the xen console 
> changes be removed and a consistent model for the console be used?

Something that might be interesting is providing a virtual CGA buffer 
for para-virtual guests.  This would be a reasonable step in the right 
direction as then we could implement a pretty reasonable VNC client that 
showed either the CGA buffer or the VNC buffer (once Xvnc started).

Considering the typical usage model this would probably be more than 
enough for most Linux users and saves a lot of cycles rendering the 
fonts (over a VGA solution).  Actually, I guess a virtual VGA device 
that also had a CGA mode would be the best of both worlds.

Regards,

Anthony Liguori

> (I'd guess the console was done the way it was because something was 
> needed and it was easiest to do it the way it is done, but is it 
> necessary now that the emulation code is available?) If there is a 
> requirement that the text mode console talk via a xen channel to the 
> xen tools, can it be done in addition to the emulation?
>
> John Byrne
>
>
>>
>>> My undertanding is that the xen changes to the Linux kernel include 
>>> changes to the console driver to talk to the xen tools and that is 
>>> you want and X server, you run Xvnc. So, looking at the text console 
>>> and the X server require different tools.
>>>
>>> If I were trying to manage virtual machines, I'd want a solution 
>>> that didn't care about what kind of kernel I was running.
>>>
>>> John Byrne
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>
>>
>
>