Prev: [PATCH 15/18] Implement getnsboottime kernel API
Next: [PATCH 11/18] Perform hardware_enable in CPU_STARTING callback
From: Zachary Amsden on 12 Jul 2010 22:30 Discovered brammage in patches due to unresolved merge. Also, had to move 09/18 past 08/18 to resolve compile issue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joerg Roedel on 16 Jul 2010 09:20 On Mon, Jul 12, 2010 at 04:25:20PM -1000, Zachary Amsden wrote: > Discovered brammage in patches due to unresolved merge. > Also, had to move 09/18 past 08/18 to resolve compile issue. Have you tested this patchset with Nested SVM? We had TSC handling related bugs there in the past and should make sure to keep it working. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Zachary Amsden on 16 Jul 2010 13:30 On 07/16/2010 03:19 AM, Joerg Roedel wrote: > On Mon, Jul 12, 2010 at 04:25:20PM -1000, Zachary Amsden wrote: > >> Discovered brammage in patches due to unresolved merge. >> Also, had to move 09/18 past 08/18 to resolve compile issue. >> > Have you tested this patchset with Nested SVM? We had TSC handling > related bugs there in the past and should make sure to keep it working. > I've been very careful to keep nested SVM safe, but I've not got a good test for that. Is there any test suite for the nested case? It took a lot of guessing to figure out why it works and why the code looks imbalanced, but I now understand the way it is now is logical and correct. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joerg Roedel on 16 Jul 2010 15:30 On Fri, Jul 16, 2010 at 07:20:32AM -1000, Zachary Amsden wrote: > I've been very careful to keep nested SVM safe, but I've not got a good > test for that. Is there any test suite for the nested case? To test this you can boot a nested Linux guest and let both, L1 and L2 guest use kvm_clock. Then put some load into the L2 guest and see if the L2 or the L1 freezes hard (which happens with kvm_clock when the TSC went backwards for one of them). Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 18 Jul 2010 10:30
On 07/16/2010 10:26 PM, Joerg Roedel wrote: > On Fri, Jul 16, 2010 at 07:20:32AM -1000, Zachary Amsden wrote: > > >> I've been very careful to keep nested SVM safe, but I've not got a good >> test for that. Is there any test suite for the nested case? >> > To test this you can boot a nested Linux guest and let both, L1 and L2 > guest use kvm_clock. Then put some load into the L2 guest and see if the > L2 or the L1 freezes hard (which happens with kvm_clock when the TSC > went backwards for one of them). > > With recent guests, they won't freeze any more, since we detect the tsc going backwards and compensate (in a brute-force way, nothing clever). But you can printk the maximum compensation and see if it's something unreasonable. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |