On 22/06/2015 10:43, Michael S. Tsirkin wrote:
Given that support is known to be partial, would it make sense to keep it disabled by default for 2.4?
What is partial about it? In fact, considering that q35 behavior is still experimental it makes no sense to even make it conditional. We discussed this on IRC and I was hoping to hear you reply "sorry, I was wrong". Instead, I get this.
Michael, I'm seriously getting annoyed by this behavior. Stop scaring away contributors.
Paolo
This way in 2.5 we won't need to add more flags to stay bug compatible.
On Mon, Jun 22, 2015 at 11:45:31AM +0200, Paolo Bonzini wrote:
On 22/06/2015 10:43, Michael S. Tsirkin wrote:
Given that support is known to be partial, would it make sense to keep it disabled by default for 2.4?
What is partial about it?
Ow, looks like I didn't send out the response to the patch itself. Will do.
In fact, considering that q35 behavior is still experimental it makes no sense to even make it conditional.
I agree to this, though an option to disable seems useful for debugging, so I'm glad that Paulo implemented it. It's probably not strictly required to disable for old machine types, but why not.
We discussed this on IRC and I was hoping to hear you reply "sorry, I was wrong". Instead, I get this.
Michael, I'm seriously getting annoyed by this behavior. Stop scaring away contributors.
Paolo
Doing my best here, but I do think we need to be careful about merging things at this stage to avoid delaying the release.
This way in 2.5 we won't need to add more flags to stay bug compatible.
On Mon, June 22, 2015 9:11 am, Michael S. Tsirkin wrote:
On Mon, Jun 22, 2015 at 11:45:31AM +0200, Paolo Bonzini wrote:
On 22/06/2015 10:43, Michael S. Tsirkin wrote:
Given that support is known to be partial, would it make sense to keep it disabled by default for 2.4?
What is partial about it?
Ow, looks like I didn't send out the response to the patch itself. Will do.
In fact, considering that q35 behavior is still experimental it makes no sense to even make it conditional.
I agree to this, though an option to disable seems useful for debugging, so I'm glad that Paulo implemented it. It's probably not strictly required to disable for old machine types, but why not.
We discussed this on IRC and I was hoping to hear you reply "sorry, I was wrong". Instead, I get this.
Michael, I'm seriously getting annoyed by this behavior. Stop scaring away contributors.
Paolo
Doing my best here, but I do think we need to be careful about merging things at this stage to avoid delaying the release.
This way in 2.5 we won't need to add more flags to stay bug
compatible.
Hi Michael,
I have seen no use other than watchdog functionality of TCO. The reason I wrote it was because I was working on an internal project that needed TCO to generate SMI so that my registered SW SMI handler in firmware would get executed. If, at that time, I had it supported on QEMU that would certainly have saved a lot of time instead testing it on bare hardware :-)
Given that, I think it's OK for me to enable it by default on pc-q35-2.4 and later.
Thanks,
Paulo
On Mon, Jun 22, 2015 at 09:36:57AM -0300, Paulo Alcantara wrote:
On Mon, June 22, 2015 9:11 am, Michael S. Tsirkin wrote:
On Mon, Jun 22, 2015 at 11:45:31AM +0200, Paolo Bonzini wrote:
On 22/06/2015 10:43, Michael S. Tsirkin wrote:
Given that support is known to be partial, would it make sense to keep it disabled by default for 2.4?
What is partial about it?
Ow, looks like I didn't send out the response to the patch itself. Will do.
In fact, considering that q35 behavior is still experimental it makes no sense to even make it conditional.
I agree to this, though an option to disable seems useful for debugging, so I'm glad that Paulo implemented it. It's probably not strictly required to disable for old machine types, but why not.
We discussed this on IRC and I was hoping to hear you reply "sorry, I was wrong". Instead, I get this.
Michael, I'm seriously getting annoyed by this behavior. Stop scaring away contributors.
Paolo
Doing my best here, but I do think we need to be careful about merging things at this stage to avoid delaying the release.
This way in 2.5 we won't need to add more flags to stay bug
compatible.
Hi Michael,
I have seen no use other than watchdog functionality of TCO. The reason I wrote it was because I was working on an internal project that needed TCO to generate SMI so that my registered SW SMI handler in firmware would get executed. If, at that time, I had it supported on QEMU that would certainly have saved a lot of time instead testing it on bare hardware :-)
Given that, I think it's OK for me to enable it by default on pc-q35-2.4 and later.
Thanks,
Paulo
OK. Do you agree to move the ACPI bits to the SSDT, making it conditional on device being enabled?
-- Paulo Alcantara, C.E.S.A.R Speaking for myself only.
On 22/06/2015 14:44, Michael S. Tsirkin wrote:
OK. Do you agree to move the ACPI bits to the SSDT, making it conditional on device being enabled?
Again, no. The chipset configuration registers range is always defined by the chipset, even if the TCO is not in use. It would have to be conditional on whether the RCBA is programmed by the firmware, not on whether the TCO watchdog is enabled. That's a very different patch, and it's independent of DSDT vs. SSDT.
You have to draw a line between required work and nice-to-haves that the maintainer can do himself. Otherwise, the possibilities are:
1) the contributor is scared away, and we lose a valuable feature
2) the contributor does it, but then keeps all remaining contributions in house because the first one was such a hell to go through.
Paolo
-
Michael S. Tsirkin -
Paolo Bonzini -
Paulo Alcantara