KVM call agenda for 2012-11-12
Hi
Please send in any agenda topics you are interested in.
Later, Juan.
Quoted 6 lines · Juan Quintela
Hi
Please send in any agenda topics you are interested in.
Later, Juan.
It would be good to have a status report on qemu-kvm compatibility (the remaining TODO items are with Anthony). They are:
- qemu-kvm 1.2 machine type.
- default accelerator being KVM.
Note migration will remain broken due to
https://patchwork.kernel.org/patch/1674521/
BTW, this can be via email, if preferred (i cannot attend the call).
Quoted 11 lines · Marcelo Tosatti
Quoted 6 lines · Juan Quintela
Hi
Please send in any agenda topics you are interested in.
Later, Juan.
It would be good to have a status report on qemu-kvm compatibility (the remaining TODO items are with Anthony). They are:
Quoted 8 lines
- qemu-kvm 1.2 machine type.
- default accelerator being KVM.Note migration will remain broken due to
https://patchwork.kernel.org/patch/1674521/
BTW, this can be via email, if preferred (i cannot attend the call).
Let's cancel the call and I'll spend the hour writing up the patches and sending them out.
Regards,
Anthony Liguori
Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 16 lines · Anthony Liguori
Quoted 14 lines · Marcelo Tosatti
Quoted 6 lines · Juan Quintela
Hi
Please send in any agenda topics you are interested in.
Later, Juan.
It would be good to have a status report on qemu-kvm compatibility (the remaining TODO items are with Anthony). They are:
- qemu-kvm 1.2 machine type.
- default accelerator being KVM.
Quoted 8 lines
Quoted 5 lines
Note migration will remain broken due to
https://patchwork.kernel.org/patch/1674521/
BTW, this can be via email, if preferred (i cannot attend the call).
Let's cancel the call and I'll spend the hour writing up the patches and sending them out.
Same for Eduardo requsets?
Later, Juan.
Quoted 19 lines · Juan Quintela
Quoted 18 lines · Anthony Liguori
Quoted 16 lines · Marcelo Tosatti
Quoted 6 lines · Juan Quintela
Hi
Please send in any agenda topics you are interested in.
Later, Juan.
It would be good to have a status report on qemu-kvm compatibility (the remaining TODO items are with Anthony). They are:
- qemu-kvm 1.2 machine type.
- default accelerator being KVM.Note migration will remain broken due to
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
https://patchwork.kernel.org/patch/1674521/
BTW, this can be via email, if preferred (i cannot attend the call).
Let's cancel the call and I'll spend the hour writing up the patches and sending them out.
Same for Eduardo requsets?
I'm happy with Andreas' clarifications, so it's OK to me.
Signature · 1 line
Eduardo
Quoted 4 lines · Juan Quintela
Hi
Please send in any agenda topics you are interested in.
- Clarify 1.3 plans for CPU: DeviceState CPU, x86 CPU classes, x86 CPU properties (we still want to get any of this included, or all will have to wait for 1.4?)
Signature · 1 line
Eduardo
Am 13.11.2012 13:29, schrieb Eduardo Habkost:
Quoted 5 lines · Juan Quintela
Quoted 2 lines
Please send in any agenda topics you are interested in.
- Clarify 1.3 plans for CPU:
From my submaintainer POV:
Quoted 1 line
DeviceState CPU,
I was specifically tasked with the qdev split by Anthony, so unless major obstacles arise I will send a PULL until Thursday.
What I am still unsure about is whether it makes sense to actually apply the final CPU-as-device change for v1.3 since that exposes the device name(s) as public "ABI", cf. below. A safety option would be no_user = 1 to avoid users messing with untested use cases at this time.
Quoted 1 line
x86 CPU classes,
If I get through review quickly enough and RFC seems sane and I get a PATCH, I might include it in the pull. To me, classes are prerequisites to exposing CPU-as-a-device because otherwise the user specifies the base class that we want to make abstract (which will then break backwards compatibility) and has no API to set it to something useful. Once applied, we would still have half a month for testing.
Quoted 1 line
x86 CPU properties
Won't make v1.3 due to timing constraints. There are also still unresolved review comments related to property naming IIRC.
Quoted 1 line
(we still want to get any of this included, or all will have to wait for 1.4?)
Regards,
Andreas
Signature · 2 lines
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Quoted 11 lines · Andreas Färber
Am 13.11.2012 13:29, schrieb Eduardo Habkost:
Quoted 5 lines · Juan Quintela
Quoted 2 lines
Please send in any agenda topics you are interested in.
- Clarify 1.3 plans for CPU:
From my submaintainer POV:
Quoted 1 line
DeviceState CPU,
Quoted 7 lines
I was specifically tasked with the qdev split by Anthony, so unless major obstacles arise I will send a PULL until Thursday.
What I am still unsure about is whether it makes sense to actually apply the final CPU-as-device change for v1.3 since that exposes the device name(s) as public "ABI", cf. below. A safety option would be
no_user= 1 to avoid users messing with untested use cases at this time.
I'm OK with holding the final TYPE_DEVICE patch, while including only the other changes. Our main problem is coordinating/rebasing work on those large patch series, so at least including the qdev split and header fixes would already make our lives easier.
Quoted 9 lines
Quoted 2 lines
x86 CPU classes,
If I get through review quickly enough and RFC seems sane and I get a PATCH, I might include it in the pull. To me, classes are prerequisites to exposing CPU-as-a-device because otherwise the user specifies the base class that we want to make abstract (which will then break backwards compatibility) and has no API to set it to something useful. Once applied, we would still have half a month for testing.
We still have some ongoing discussion about the CPU class namespace, and how to map the name from "-cpu FOO" to the actual class name, so I don't think we want to hurry to get the RFC in 1.3. I will try to rewrite it in a way that allows all targets to use the same code to find the appropriate CPU class.
Maybe we could just try to include just the cpu_x86_init() cleanups I sent yesterday, to make further work easier to coordinate?
(It's not that important to get that in 1.3, anyway, we can just agree to use that series as base for futher work, even if it doesn't get included right now)
Quoted 5 lines
Quoted 2 lines
x86 CPU properties
Won't make v1.3 due to timing constraints. There are also still unresolved review comments related to property naming IIRC.
OK. It still has to be rebased, so I didn't think it was feasible for 1.3.
Quoted 10 lines
Quoted 2 lines
(we still want to get any of this included, or all will have to wait for 1.4?)
Regards,
AndreasSignature · 2 lines
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Signature · 1 line
Eduardo
HI,
I'm got confused by the date in this topic.
Quoted 10 lines · Juan Quintela
Hi
Please send in any agenda topics you are interested in.
Later, Juan.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 3 lines
Regards, Zhi Yong Wu