Jeremy Fitzhardinge
2007-Jul-18 19:58 UTC
[Xen-devel] Xen domU support merged into upstream Linux
I''m pleased to announce that Linus has just merged my Xen patches into upstream git, so they will be released as part of 2.6.23. The patches are 32-bit domU support, including: * netfront * blockfront * hvc console * SMP guests Notable missing features at the moment are support ballooning and suspend/migrate/resume, as well as dom0 and 64-bit support. But they''re all on the TODO list. And, as always, patches accepted ;) J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Williamson
2007-Jul-24 17:07 UTC
Re: [Xen-devel] Xen domU support merged into upstream Linux
> I''m pleased to announce that Linus has just merged my Xen patches into > upstream git, so they will be released as part of 2.6.23.Many congratulations Jeremy, that''s great news. Huge props for taking this and making it really happen. Hopefully it''ll be a real boost for Xen.> The patches are 32-bit domU support, including: > > * netfront > * blockfront > * hvc console > * SMP guestsThat''s a nice range of functionality - all the really important core things.> Notable missing features at the moment are support ballooning and > suspend/migrate/resume,Out of interest, is there a particular issue with these, or is it just a case of concentrating on getting the core code in mainline first?> as well as dom0 and 64-bit support. But they''re > all on the TODO list.I guess x86_64 is waiting on paravirt_ops stuff for that architecture, right? I guess dom0 support will probably have to be refactored somehow to be acceptable to mainline anyhow, but I presume we''ll need (something like) more paravirt_ops too, right? Just curious as to what the future work would look like and where patches are likely to be focusing.> And, as always, patches accepted ;)Noted ;-) I''ve got a git snapshot here to play with. Are there any particular areas where you''re looking for patches? e.g. things that need doing, but you don''t have time to look at immediately, or bits of infrastructure that need investigating? Also, do you have any thoughts on Rusty''s virtio stuff? Sorry for all the random questions, well done anyhow - great stuff. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2007-Jul-25 00:15 UTC
Re: [Xen-devel] Xen domU support merged into upstream Linux
Mark Williamson wrote:>> * netfront >> * blockfront >> * hvc console >> * SMP guests >> > > That''s a nice range of functionality - all the really important core things. > > >> Notable missing features at the moment are support ballooning and >> suspend/migrate/resume, >> > > Out of interest, is there a particular issue with these, or is it just a case > of concentrating on getting the core code in mainline first? >Mostly it was about getting a minimal useful set in early. Originally it was going to be UP only, but SMP turned out to be much easier than I expected. Suspend/resume interacts badly with preempt (which is supported). I''ve been trying to work out how to get them to play together, but I suspect we''ll just need to make CONFIG_XEN_SUSPEND depend on !PREEMPT for now. There are no particular problems with balloon, but it seems to me that it could be dealt with a little better. Maybe some combination of memory hotplug+traditional ballooning. Also, it became apparent at the virtualization minisummit that balloon has a lot of common elements in the various virtualization systems, and it might be worth making that more universal - particularly the policy engine of distributing memory across all the domain (I don''t know if this is a particular problem at the moment, but it seems that s390 has some fairly reusable code we might want to look at).>> as well as dom0 and 64-bit support. But they''re >> all on the TODO list. >> > > I guess x86_64 is waiting on paravirt_ops stuff for that architecture, right? >Yes, I''m looking at how that''s playing out, particularly since Ingo and Thomas Gleixner''s arch/x86 proposal the other day.> I guess dom0 support will probably have to be refactored somehow to be > acceptable to mainline anyhow, but I presume we''ll need (something like) more > paravirt_ops too, right? >Yes. Well, maybe. Unlike all the guest stuff, dom0 doesn''t really have any application beyond Xen. I''m not sure whether we''ll come up with anything acceptible for mainline, but it depends on how things refactor out. I think a good initial goal is to come up with a reasonably clean and maintainable out of tree patch set.> Noted ;-) I''ve got a git snapshot here to play with. Are there any > particular areas where you''re looking for patches? e.g. things that need > doing, but you don''t have time to look at immediately, or bits of > infrastructure that need investigating? >In the short term I''m investigating dom0, since it has the most unknowns (at least for me). 64-bit will be an effort, but I don''t think there are any deep problems which need to be solved there. Most of the existing code should be fairly 64-bit clean, and support for the 4th pagetable level shouldn''t be too hard to add. Almost all of the pv-ops will still be used, simply because we still need to support 32-bit usermode. There is the open question of whether we want to support pure pv 64-bit, or if we should just go straight to a hybrid pv-hvm solution. That is, run the guest in an hvm container as ring0, use hvm to intercept a lot of the boring operations, but keep using pv pagetables, etc. How many people are using pre-HVM 64-bit guests?> Also, do you have any thoughts on Rusty''s virtio stuff? >I think its an interesting idea. If its possible to do a high performance and featureful netfront driver with it, that''s cleaner than the current code, then it will be worthwhile. But I think that''s definitely on the list of projects up for grabs.> Sorry for all the random questions, well done anyhow - great stuff.Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Oravec
2007-Jul-30 15:40 UTC
Re: [Xen-devel] Xen domU support merged into upstream Linux
Hi Jeremy, First, congratulations for merging into 2.6.23. On Tue, 2007-07-24 at 17:15 -0700, Jeremy Fitzhardinge wrote:> There is the open question of whether we want to support pure pv 64-bit, > or if we should just go straight to a hybrid pv-hvm solution. That is, > run the guest in an hvm container as ring0, use hvm to intercept a lot > of the boring operations, but keep using pv pagetables, etc. How many > people are using pre-HVM 64-bit guests? >I tend to believe there are more pre-HVM 64-bit guests than 32-bit guests. 64-bit CPUs are mainstream for a few years and 32-bit-only server systems are getting old. Almost everyone I know with 64-bit CPUs prefers to run 64-bit Linux over 32-bit. So, I think it is worth to support pre-HVM 64-bit guests. Cheers, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2007-Jul-30 16:14 UTC
Re: [Xen-devel] Xen domU support merged into upstream Linux
Jan Oravec wrote:> I tend to believe there are more pre-HVM 64-bit guests than 32-bit > guests. 64-bit CPUs are mainstream for a few years and 32-bit-only > server systems are getting old. Almost everyone I know with 64-bit CPUs > prefers to run 64-bit Linux over 32-bit. > > So, I think it is worth to support pre-HVM 64-bit guests.Well, traditionally 64-bit guests have suffered a particularly steep performance hit under Xen, so I suspect that a lot of people with 64-bit hosts are still tending to use 32-bit guests. But I''m just handwaving really. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel