Re: [Qemu-devel] Release plan for 0.12.0
On Wed, Oct 14, 2009 at 03:09:28PM +0200, Arnd Bergmann wrote: > On Thursday 08 October 2009, Anthony Liguori wrote: > > Jens Osterkamp wrote: > > > On Wednesday 30 September 2009, Anthony Liguori wrote: > > > > > >> Please add to this list and I'll collect it all and post it somewhere. > > >> > > > > > > What about Or Gerlitz' raw backend driver ? I did not see it go in yet, > > > or did > > > I miss something ? > > > > > > > The patch seems to have not been updated after the initial posting and > > the first feedback cycle. > > > > I'm generally inclined to oppose the functionality as I don't think it > > offers any advantages over the existing backends. > > There are two reasons why I think this backend is important: > > - As an easy way to provide isolation between guests (private ethernet > port aggregator, PEPA) and external enforcement of network priviledges > (virtual ethernet port aggregator, VEPA) using the macvlan subsystem. > > - As a counterpart to the vhost_net driver, providing an identical > user interface with or without vhost_net acceleration in the kernel. > > Arnd <>< I think raw sockets also support RX mac/vlan filtering in kernel, which might be faster than doing it in virtio in userspace as it's done now. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On Wed, Oct 14, 2009 at 08:53:55AM -0500, Anthony Liguori wrote: > Arnd Bergmann wrote: >> There are two reasons why I think this backend is important: >> >> - As an easy way to provide isolation between guests (private ethernet >> port aggregator, PEPA) and external enforcement of network priviledges >> (virtual ethernet port aggregator, VEPA) using the macvlan subsystem. >> > > Can't this all be done with tap and a bridge? Not with existing kernels, I think. > Regards, > > Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
Arnd Bergmann wrote: There are two reasons why I think this backend is important: - As an easy way to provide isolation between guests (private ethernet port aggregator, PEPA) and external enforcement of network priviledges (virtual ethernet port aggregator, VEPA) using the macvlan subsystem. Can't this all be done with tap and a bridge? Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On Thursday 08 October 2009, Anthony Liguori wrote: > Jens Osterkamp wrote: > > On Wednesday 30 September 2009, Anthony Liguori wrote: > > > >> Please add to this list and I'll collect it all and post it somewhere. > >> > > > > What about Or Gerlitz' raw backend driver ? I did not see it go in yet, or > > did > > I miss something ? > > > > The patch seems to have not been updated after the initial posting and > the first feedback cycle. > > I'm generally inclined to oppose the functionality as I don't think it > offers any advantages over the existing backends. There are two reasons why I think this backend is important: - As an easy way to provide isolation between guests (private ethernet port aggregator, PEPA) and external enforcement of network priviledges (virtual ethernet port aggregator, VEPA) using the macvlan subsystem. - As a counterpart to the vhost_net driver, providing an identical user interface with or without vhost_net acceleration in the kernel. Arnd <>< -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
Jens Osterkamp wrote: On Wednesday 30 September 2009, Anthony Liguori wrote: o VMState conversion -- I expect most of the pc target to be completed o qdev conversion -- I hope that we'll get most of the pc target completely converted to qdev o storage live migration o switch to SeaBIOS (need to finish porting features from Bochs) o switch to gPXE (need to resolve slirp tftp server issue) o KSM integration o in-kernel APIC support for KVM o guest SMP support for KVM o updates to the default pc machine type Please add to this list and I'll collect it all and post it somewhere. What about Or Gerlitz' raw backend driver ? I did not see it go in yet, or did I miss something ? The patch seems to have not been updated after the initial posting and the first feedback cycle. I'm generally inclined to oppose the functionality as I don't think it offers any advantages over the existing backends. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On Wednesday 30 September 2009, Anthony Liguori wrote: > o VMState conversion -- I expect most of the pc target to be completed > o qdev conversion -- I hope that we'll get most of the pc target > completely converted to qdev > o storage live migration > o switch to SeaBIOS (need to finish porting features from Bochs) > o switch to gPXE (need to resolve slirp tftp server issue) > o KSM integration > o in-kernel APIC support for KVM > o guest SMP support for KVM > o updates to the default pc machine type > > Please add to this list and I'll collect it all and post it somewhere. What about Or Gerlitz' raw backend driver ? I did not see it go in yet, or did I miss something ? Jens -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On 10/05/2009 02:43 PM, Luiz Capitulino wrote: Are you using a standard json parser with your test script? That's an additional validation. I'm using Python's json module, but I could run one of the checkers listed in the json's page for each test, before the Python's module kicks in. python-json should be sufficient, I think. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On Sat, 03 Oct 2009 12:04:57 +0200 Avi Kivity wrote: > On 10/01/2009 11:13 PM, Luiz Capitulino wrote: > >> If we're going to support the protocol for 0.12, I'd like to most of the > >> code merged by the end of October. > >> > > Four weeks.. Not so much time, but let's try. > > > > There are two major issues that may delay QMP. > > > > Firstly, we are still on the infrastructure/design phase, which > > is natural to take time. Maybe when handlers start getting converted > > en masse things will be faster. > > > > I sure hope so. Maybe someone can pitch in if not. I've written a TODO list if someone is willing to help: http://tinyurl.com/ya7l6bo > > Secondly: testing. I have a very ugly python script to test the > > already converted handlers. The problem is not only the ugliness, > > the right way to do this would be to use kvm-autotest. So, I was > > planning to take a detailed look at it and perhaps start writing > > tests for QMP right when each handler is converted. Right Thing, > > but takes time. > > > > I think this could be done by having autotest use two monitors, one with > the machine protocol and one with the human protocol, trying first the > machine protocol and falling back if the command is not supported. Yes, sounds a good idea. > Hopefully we can get the autotest people to work on it so we parallelize > development. They'll also give user-oriented feedback which can be > valuable. I will talk to them about that. > Are you using a standard json parser with your test script? That's an > additional validation. I'm using Python's json module, but I could run one of the checkers listed in the json's page for each test, before the Python's module kicks in. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On 10/01/2009 11:13 PM, Luiz Capitulino wrote: If we're going to support the protocol for 0.12, I'd like to most of the code merged by the end of October. Four weeks.. Not so much time, but let's try. There are two major issues that may delay QMP. Firstly, we are still on the infrastructure/design phase, which is natural to take time. Maybe when handlers start getting converted en masse things will be faster. I sure hope so. Maybe someone can pitch in if not. Secondly: testing. I have a very ugly python script to test the already converted handlers. The problem is not only the ugliness, the right way to do this would be to use kvm-autotest. So, I was planning to take a detailed look at it and perhaps start writing tests for QMP right when each handler is converted. Right Thing, but takes time. I think this could be done by having autotest use two monitors, one with the machine protocol and one with the human protocol, trying first the machine protocol and falling back if the command is not supported. Hopefully we can get the autotest people to work on it so we parallelize development. They'll also give user-oriented feedback which can be valuable. Are you using a standard json parser with your test script? That's an additional validation. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
Anthony Liguori さんは書きました: >Hi, > >Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. > >I'd like to do a few things different this time around. I don't think >the -rc process went very well as I don't think we got more testing out >of it. I'd like to shorten the timeline for 0.12.0 a good bit. The >0.10 stable tree got pretty difficult to maintain toward the end of the >cycle. We also had a pretty huge amount of change between 0.10 and 0.11 >so I think a shorter cycle is warranted. > >I think aiming for early to mid-December would give us roughly a 3 month >cycle and would align well with some of the Linux distribution cycles. >I'd like to limit things to a single -rc that lasted only for about a >week. This is enough time to fix most of the obvious issues I think. > >I'd also like to try to enumerate some features for this release. >Here's a short list of things I expect to see for this release >(target-i386 centric). Please add or comment on items that you'd either >like to see in the release or are planning on working on. > > o VMState conversion -- I expect most of the pc target to be completed > o qdev conversion -- I hope that we'll get most of the pc target >completely converted to qdev > o storage live migration > o switch to SeaBIOS (need to finish porting features from Bochs) > o switch to gPXE (need to resolve slirp tftp server issue) > o KSM integration > o in-kernel APIC support for KVM > o guest SMP support for KVM > o updates to the default pc machine type > >Please add to this list and I'll collect it all and post it somewhere. o NEC PC-9821 family support on target-i386 In the last patch MS-DOS can boot on QEMU. I think I can add support nic (LGY-98) and IDE in 0.12.0 and I hope I can boot FreeBSD/pc98 on it. PS. I will repost v3 patch in the next week, please wait reviewing v2 patch I post Oct.1. Thanks, TAKEDA, toshiya >Thanks! > >-- >Regards, > >Anthony Liguori > > > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On Wed, 30 Sep 2009 08:05:16 -0500 Anthony Liguori wrote: > Avi Kivity wrote: > > On 09/30/2009 01:54 AM, Anthony Liguori wrote: > >> Hi, > >> > >> Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. > >> > >> I'd like to do a few things different this time around. I don't > >> think the -rc process went very well as I don't think we got more > >> testing out of it. I'd like to shorten the timeline for 0.12.0 a > >> good bit. The 0.10 stable tree got pretty difficult to maintain > >> toward the end of the cycle. We also had a pretty huge amount of > >> change between 0.10 and 0.11 so I think a shorter cycle is warranted. > >> > >> I think aiming for early to mid-December would give us roughly a 3 > >> month cycle and would align well with some of the Linux distribution > >> cycles. I'd like to limit things to a single -rc that lasted only > >> for about a week. This is enough time to fix most of the obvious > >> issues I think. > >> > >> I'd also like to try to enumerate some features for this release. > >> Here's a short list of things I expect to see for this release > >> (target-i386 centric). Please add or comment on items that you'd > >> either like to see in the release or are planning on working on. > >> > >> o VMState conversion -- I expect most of the pc target to be completed > >> o qdev conversion -- I hope that we'll get most of the pc target > >> completely converted to qdev > >> o storage live migration > >> o switch to SeaBIOS (need to finish porting features from Bochs) > >> o switch to gPXE (need to resolve slirp tftp server issue) > >> o KSM integration > >> o in-kernel APIC support for KVM > >> o guest SMP support for KVM > >> o updates to the default pc machine type > > > > Machine monitor protocol. > > If we're going to support the protocol for 0.12, I'd like to most of the > code merged by the end of October. Four weeks.. Not so much time, but let's try. There are two major issues that may delay QMP. Firstly, we are still on the infrastructure/design phase, which is natural to take time. Maybe when handlers start getting converted en masse things will be faster. Secondly: testing. I have a very ugly python script to test the already converted handlers. The problem is not only the ugliness, the right way to do this would be to use kvm-autotest. So, I was planning to take a detailed look at it and perhaps start writing tests for QMP right when each handler is converted. Right Thing, but takes time. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On 09/30/09 16:45, Anthony Liguori wrote: One reason I branch is because some people care a bit less about releases so it makes the process non-disruptive to them. If the other maintainers agreed though, I would certainly like to have the master branch essentially frozen for the week before the release. We had much longer disruptions without a release freeze, so why worry about a single week? One week freeze is short enougth that the disruption isn't a big issue. It will help testing the to-be-released code. Go for it. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On Wed, Sep 30, 2009 at 6:59 PM, Carl-Daniel Hailfinger wrote: > On 30.09.2009 15:07, Anthony Liguori wrote: >> Carl-Daniel Hailfinger wrote: >>> However, to run coreboot on Qemu with the same init sequence as on >>> simplified real hardware, we need Cache-as-RAM (CAR) support. [...] >> >> Do we really need coreboot to use the same init sequence? coreboot >> is firmware and we don't necessarily run real firmware under QEMU. >> It's a short cut that lets us avoid a lot of complexity. > > I know that some people were running 440BX BIOS images for real hardware > on Qemu and they got pretty far. > > The complexity would be limited to the MTRR code and unless there were > major architectural changes in mapping RAM to address ranges, no other > code (except VM save and VM restore) should get even a single line changed. > >>> Right now coreboot sets up the MTRRs correctly, but then (conditional on >>> Qemu) only uses areas which are known to be backed by RAM instead of the >>> areas designated by CAR. >>> >>> I'd like to implement CAR support which builds on top of my MTRR code >>> which was merged some months ago (and I already have code to check for >>> total cacheable area size), but I need help with the memory mapping >>> stuff. How do I proceed? Clean up what I have and insert "FIXME" >>> comments where I don't know how to implement stuff so others can see the >>> code and comment on it? >> >> You could start there. But from a higher level, I'm not sure I think >> a partial implementation of something like CAR is all that valuable >> since coreboot already runs under QEMU. > > It only runs if WORKAROUND_QEMU is defined (maybe not exactly that name, > but you get the point). The code in coreboot calculates MTRR settings to > cover the place where the stack will be. To workaround missing CAR in > Qemu, it then has to recalculate the stack location to be able to > actually use the stack. That forces coreboot to keep two stack base > variables and to completely replace the generic logic which switches off > CAR. > > I hope the explanation above didn't offend you, I just tried to clarify > why working CAR is such a big deal for coreboot. > > If you want either a full CAR implementation or no CAR implementation, I > can write a patch which implements full CAR, but then I need to hook > WBINVD, INVD and CLFLUSH. Neither instruction is executed often enough > to show up in any profile. Besides that, for anything not using CAR > (everything after the firmware), the penalty is a simple test of a > boolean variable per WBINVD/INVD/CLFLUSH. The CAR mode could affect only translation so that special CAR versions of the WBINVD etc. instructions are selected. On switch to normal mode, the TBs need to be flushed. Instead of your memory mapping approach (which should work) you could also try using different memory access functions in CAR mode. It may be more difficult, though. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On 30.09.2009 15:07, Anthony Liguori wrote: > Carl-Daniel Hailfinger wrote: >> However, to run coreboot on Qemu with the same init sequence as on >> simplified real hardware, we need Cache-as-RAM (CAR) support. [...] > > Do we really need coreboot to use the same init sequence? coreboot > is firmware and we don't necessarily run real firmware under QEMU. > It's a short cut that lets us avoid a lot of complexity. I know that some people were running 440BX BIOS images for real hardware on Qemu and they got pretty far. The complexity would be limited to the MTRR code and unless there were major architectural changes in mapping RAM to address ranges, no other code (except VM save and VM restore) should get even a single line changed. >> Right now coreboot sets up the MTRRs correctly, but then (conditional on >> Qemu) only uses areas which are known to be backed by RAM instead of the >> areas designated by CAR. >> >> I'd like to implement CAR support which builds on top of my MTRR code >> which was merged some months ago (and I already have code to check for >> total cacheable area size), but I need help with the memory mapping >> stuff. How do I proceed? Clean up what I have and insert "FIXME" >> comments where I don't know how to implement stuff so others can see the >> code and comment on it? > > You could start there. But from a higher level, I'm not sure I think > a partial implementation of something like CAR is all that valuable > since coreboot already runs under QEMU. It only runs if WORKAROUND_QEMU is defined (maybe not exactly that name, but you get the point). The code in coreboot calculates MTRR settings to cover the place where the stack will be. To workaround missing CAR in Qemu, it then has to recalculate the stack location to be able to actually use the stack. That forces coreboot to keep two stack base variables and to completely replace the generic logic which switches off CAR. I hope the explanation above didn't offend you, I just tried to clarify why working CAR is such a big deal for coreboot. If you want either a full CAR implementation or no CAR implementation, I can write a patch which implements full CAR, but then I need to hook WBINVD, INVD and CLFLUSH. Neither instruction is executed often enough to show up in any profile. Besides that, for anything not using CAR (everything after the firmware), the penalty is a simple test of a boolean variable per WBINVD/INVD/CLFLUSH. If you have further questions, please don't hesitate to ask. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On Wed, 30 Sep 2009 17:03:23 +0200 Fred Leeflang wrote: > 2009/9/30 Anthony Liguori > > > Luiz Capitulino wrote: > > > >> On Tue, 29 Sep 2009 18:54:53 -0500 > >> Anthony Liguori wrote: > >> > >> > >> > >>> I think aiming for early to mid-December would give us roughly a 3 month > >>> cycle and would align well with some of the Linux distribution cycles. > >>> I'd > >>> like to limit things to a single -rc that lasted only for about a week. > >>> This is enough time to fix most of the obvious issues I think. > >>> > >>> > >> > >> How do you plan to do it? I mean, are you going to create a separate > >> branch > >> or make master the -rc? > >> > >> Creating a separate branch (which is what we do today, iiuc) makes it > >> get less attention, freezing master for a certain period is the best > >> way to stabilize. > >> > >> Is this what you had in mind? > >> > >> > > What do people think? > > > > One reason I branch is because some people care a bit less about releases > > so it makes the process non-disruptive to them. If the other maintainers > > agreed though, I would certainly like to have the master branch essentially > > frozen for the week before the release. > > > > freezing is only neccesary if you need time to gather all the patches, build > and test them together etc. Not exactly, freezing is done to stop/slowdown writing new code and focus on bug fixing for a period of time. This is not only needed for a release, but projects should always try to find the best balance between 'number of bugs' and 'feature addition rate'. > If you don't feel you or the developers need to > do that to get a reliable release out I think it only halts developers > without any clear reason to do so. Calling 'attention' to a release is not a > clear reason IMO. Having a functional and relatively stable release is not only important, but it's the ultimate goal IMO. Obviously we should take care not to take extremes. No QEMU release will be 100% bug free, that's why we have stables. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
Luiz Capitulino wrote: On Tue, 29 Sep 2009 18:54:53 -0500 Anthony Liguori wrote: I think aiming for early to mid-December would give us roughly a 3 month cycle and would align well with some of the Linux distribution cycles. I'd like to limit things to a single -rc that lasted only for about a week. This is enough time to fix most of the obvious issues I think. How do you plan to do it? I mean, are you going to create a separate branch or make master the -rc? Creating a separate branch (which is what we do today, iiuc) makes it get less attention, freezing master for a certain period is the best way to stabilize. Is this what you had in mind? What do people think? One reason I branch is because some people care a bit less about releases so it makes the process non-disruptive to them. If the other maintainers agreed though, I would certainly like to have the master branch essentially frozen for the week before the release. -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On Wed, Sep 30, 2009 at 08:03:20AM -0500, Anthony Liguori wrote: > Hi Isaku, > > Isaku Yamahata wrote: >> o newer chipset (which is based on Q35 chipset) >> o multiple pci bus o PCI express (MMCONFIG) >> o PCI express hot plug (not acpi based) >> o PCI express switch emulator >> >> Although there is no PCIe emulated device at the moment, this will be a >> fundamental infrastructure for PCI express native >> direct attach. >> > > Your patches definitely deserve review/commit. I'll make sure that > happens for the 0.12 time frame. > > Michael, could you help review some of the PCI patches? Yes, I am doing this sent comments already. The only thing I have not looked at yet is the new express file. > Thanks, > > -- > Regards, > > Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On Wed, 30 Sep 2009 08:41:23 +0200 Avi Kivity wrote: > On 09/30/2009 01:54 AM, Anthony Liguori wrote: > > Hi, > > > > Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. > > > > I'd like to do a few things different this time around. I don't think > > the -rc process went very well as I don't think we got more testing > > out of it. I'd like to shorten the timeline for 0.12.0 a good bit. > > The 0.10 stable tree got pretty difficult to maintain toward the end > > of the cycle. We also had a pretty huge amount of change between 0.10 > > and 0.11 so I think a shorter cycle is warranted. > > > > I think aiming for early to mid-December would give us roughly a 3 > > month cycle and would align well with some of the Linux distribution > > cycles. I'd like to limit things to a single -rc that lasted only for > > about a week. This is enough time to fix most of the obvious issues I > > think. > > > > I'd also like to try to enumerate some features for this release. > > Here's a short list of things I expect to see for this release > > (target-i386 centric). Please add or comment on items that you'd > > either like to see in the release or are planning on working on. > > > > o VMState conversion -- I expect most of the pc target to be completed > > o qdev conversion -- I hope that we'll get most of the pc target > > completely converted to qdev > > o storage live migration > > o switch to SeaBIOS (need to finish porting features from Bochs) > > o switch to gPXE (need to resolve slirp tftp server issue) > > o KSM integration > > o in-kernel APIC support for KVM > > o guest SMP support for KVM > > o updates to the default pc machine type > > Machine monitor protocol. Yeah, I was going to suggest it as well. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On Tue, 29 Sep 2009 18:54:53 -0500 Anthony Liguori wrote: > I think aiming for early to mid-December would give us roughly a 3 month > cycle and would align well with some of the Linux distribution cycles. > I'd like to limit things to a single -rc that lasted only for about a > week. This is enough time to fix most of the obvious issues I think. How do you plan to do it? I mean, are you going to create a separate branch or make master the -rc? Creating a separate branch (which is what we do today, iiuc) makes it get less attention, freezing master for a certain period is the best way to stabilize. Is this what you had in mind? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
Carl-Daniel Hailfinger wrote: Hi, On 30.09.2009 01:54, Anthony Liguori wrote: Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. I'd also like to try to enumerate some features for this release. Here's a short list of things I expect to see for this release (target-i386 centric). o switch to SeaBIOS (need to finish porting features from Bochs) That switch is much appreciated because it also reduces the testing matrix of those coreboot developers who boot test every commit with Qemu. However, to run coreboot on Qemu with the same init sequence as on simplified real hardware, we need Cache-as-RAM (CAR) support. This is basically a mode where sizeof(cacheable area) <= sizeof (L2 cache) and causes the processor to lock the cache and not pass any reads/writes through to the RAM behind the cached area. The easiest way to implement this would be to check the cache size criterion upon every MTRR manipulation and either map a chunk of fresh memory on top of the existing memory (which may be RAM, ROM or unmapped) for every cacheable area, and if the cacheable area starts to exceed the L2 cache size, discard all memory contents of the memory mapped on top. For additional correctness, the memory shoud not be discarded and written back to the lower layer of memory if WBINVD (instead of INVD) or CLFLUSH are called. That one is mostly sugar, though, and coreboot can do without. Do we really need coreboot to use the same init sequence? coreboot is firmware and we don't necessarily run real firmware under QEMU. It's a short cut that lets us avoid a lot of complexity. Right now coreboot sets up the MTRRs correctly, but then (conditional on Qemu) only uses areas which are known to be backed by RAM instead of the areas designated by CAR. I'd like to implement CAR support which builds on top of my MTRR code which was merged some months ago (and I already have code to check for total cacheable area size), but I need help with the memory mapping stuff. How do I proceed? Clean up what I have and insert "FIXME" comments where I don't know how to implement stuff so others can see the code and comment on it? You could start there. But from a higher level, I'm not sure I think a partial implementation of something like CAR is all that valuable since coreboot already runs under QEMU. Regards, Carl-Daniel -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
Avi Kivity wrote: On 09/30/2009 01:54 AM, Anthony Liguori wrote: Hi, Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. I'd like to do a few things different this time around. I don't think the -rc process went very well as I don't think we got more testing out of it. I'd like to shorten the timeline for 0.12.0 a good bit. The 0.10 stable tree got pretty difficult to maintain toward the end of the cycle. We also had a pretty huge amount of change between 0.10 and 0.11 so I think a shorter cycle is warranted. I think aiming for early to mid-December would give us roughly a 3 month cycle and would align well with some of the Linux distribution cycles. I'd like to limit things to a single -rc that lasted only for about a week. This is enough time to fix most of the obvious issues I think. I'd also like to try to enumerate some features for this release. Here's a short list of things I expect to see for this release (target-i386 centric). Please add or comment on items that you'd either like to see in the release or are planning on working on. o VMState conversion -- I expect most of the pc target to be completed o qdev conversion -- I hope that we'll get most of the pc target completely converted to qdev o storage live migration o switch to SeaBIOS (need to finish porting features from Bochs) o switch to gPXE (need to resolve slirp tftp server issue) o KSM integration o in-kernel APIC support for KVM o guest SMP support for KVM o updates to the default pc machine type Machine monitor protocol. If we're going to support the protocol for 0.12, I'd like to most of the code merged by the end of October. -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
Hi Isaku, Isaku Yamahata wrote: o newer chipset (which is based on Q35 chipset) o multiple pci bus o PCI express (MMCONFIG) o PCI express hot plug (not acpi based) o PCI express switch emulator Although there is no PCIe emulated device at the moment, this will be a fundamental infrastructure for PCI express native direct attach. Your patches definitely deserve review/commit. I'll make sure that happens for the 0.12 time frame. Michael, could you help review some of the PCI patches? Thanks, -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
Hi, On 30.09.2009 01:54, Anthony Liguori wrote: > Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. > > I'd also like to try to enumerate some features for this release. > Here's a short list of things I expect to see for this release > (target-i386 centric). > > o switch to SeaBIOS (need to finish porting features from Bochs) That switch is much appreciated because it also reduces the testing matrix of those coreboot developers who boot test every commit with Qemu. However, to run coreboot on Qemu with the same init sequence as on simplified real hardware, we need Cache-as-RAM (CAR) support. This is basically a mode where sizeof(cacheable area) <= sizeof (L2 cache) and causes the processor to lock the cache and not pass any reads/writes through to the RAM behind the cached area. The easiest way to implement this would be to check the cache size criterion upon every MTRR manipulation and either map a chunk of fresh memory on top of the existing memory (which may be RAM, ROM or unmapped) for every cacheable area, and if the cacheable area starts to exceed the L2 cache size, discard all memory contents of the memory mapped on top. For additional correctness, the memory shoud not be discarded and written back to the lower layer of memory if WBINVD (instead of INVD) or CLFLUSH are called. That one is mostly sugar, though, and coreboot can do without. Right now coreboot sets up the MTRRs correctly, but then (conditional on Qemu) only uses areas which are known to be backed by RAM instead of the areas designated by CAR. I'd like to implement CAR support which builds on top of my MTRR code which was merged some months ago (and I already have code to check for total cacheable area size), but I need help with the memory mapping stuff. How do I proceed? Clean up what I have and insert "FIXME" comments where I don't know how to implement stuff so others can see the code and comment on it? Regards, Carl-Daniel -- http://www.hailfinger.org/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On 09/30/2009 10:53 AM, Michael Tokarev wrote: Anthony Liguori wrote: [] Here's a short list of things I expect to see for this release (target-i386 centric). Please add or comment on items that you'd either like to see in the release or are planning on working on. [..] o guest SMP support for KVM Hmm. What is this, can you elaborate a bit more please? -smp nn is already here, no? Only in qemu-kvm.git. This is about qemu.git (which supports -smp, but not with kvm). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
Anthony Liguori wrote: [] Here's a short list of things I expect to see for this release (target-i386 centric). Please add or comment on items that you'd either like to see in the release or are planning on working on. [..] o guest SMP support for KVM Hmm. What is this, can you elaborate a bit more please? -smp nn is already here, no? Thanks! /mjt -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On 09/30/2009 01:54 AM, Anthony Liguori wrote: Hi, Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. I'd like to do a few things different this time around. I don't think the -rc process went very well as I don't think we got more testing out of it. I'd like to shorten the timeline for 0.12.0 a good bit. The 0.10 stable tree got pretty difficult to maintain toward the end of the cycle. We also had a pretty huge amount of change between 0.10 and 0.11 so I think a shorter cycle is warranted. I think aiming for early to mid-December would give us roughly a 3 month cycle and would align well with some of the Linux distribution cycles. I'd like to limit things to a single -rc that lasted only for about a week. This is enough time to fix most of the obvious issues I think. I'd also like to try to enumerate some features for this release. Here's a short list of things I expect to see for this release (target-i386 centric). Please add or comment on items that you'd either like to see in the release or are planning on working on. o VMState conversion -- I expect most of the pc target to be completed o qdev conversion -- I hope that we'll get most of the pc target completely converted to qdev o storage live migration o switch to SeaBIOS (need to finish porting features from Bochs) o switch to gPXE (need to resolve slirp tftp server issue) o KSM integration o in-kernel APIC support for KVM o guest SMP support for KVM o updates to the default pc machine type Machine monitor protocol. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On Tue, Sep 29, 2009 at 06:54:53PM -0500, Anthony Liguori wrote: > Hi, > > Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. > > I'd like to do a few things different this time around. I don't think > the -rc process went very well as I don't think we got more testing out > of it. I'd like to shorten the timeline for 0.12.0 a good bit. The > 0.10 stable tree got pretty difficult to maintain toward the end of the > cycle. We also had a pretty huge amount of change between 0.10 and 0.11 > so I think a shorter cycle is warranted. > > I think aiming for early to mid-December would give us roughly a 3 month > cycle and would align well with some of the Linux distribution cycles. > I'd like to limit things to a single -rc that lasted only for about a > week. This is enough time to fix most of the obvious issues I think. > > I'd also like to try to enumerate some features for this release. > Here's a short list of things I expect to see for this release > (target-i386 centric). Please add or comment on items that you'd either > like to see in the release or are planning on working on. > > o VMState conversion -- I expect most of the pc target to be completed > o qdev conversion -- I hope that we'll get most of the pc target > completely converted to qdev > o storage live migration > o switch to SeaBIOS (need to finish porting features from Bochs) > o switch to gPXE (need to resolve slirp tftp server issue) > o KSM integration > o in-kernel APIC support for KVM > o guest SMP support for KVM > o updates to the default pc machine type > > Please add to this list and I'll collect it all and post it somewhere. o newer chipset (which is based on Q35 chipset) o multiple pci bus o PCI express (MMCONFIG) o PCI express hot plug (not acpi based) o PCI express switch emulator Although there is no PCIe emulated device at the moment, this will be a fundamental infrastructure for PCI express native direct attach. thanks, -- yamahata -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
