On 05/24/2012 01:00 AM, Thomas Gleixner wrote:
Thought more about that.
We have a clear distinction between HW accessed data and software
accessed data.
If I look at TPR then it is special cased already and it does:
case APIC_TASKPRI:
report_tpr_access(apic,
* Avi Kivity a...@redhat.com wrote:
On 05/22/2012 02:01 AM, Thomas Gleixner wrote:
Others are not my fault :)
Seriously, if Avi/Marcelo want to rewrite the ISR emulation
Interesting POV, really.
Did you ever notice that the kernel is a collaborative effort and not
On 05/23/2012 05:48 PM, Ingo Molnar wrote:
This is silly. Most of the time the kernel is advanced by
incremental patches. Sometimes it is advanced by minor or
major refactoring. It is never advanced by personal attacks
on contributors.
Thomas wasn't so much doing a personal attack,
On 05/22/2012 08:26 PM, Thomas Gleixner wrote:
On Tue, 22 May 2012, Avi Kivity wrote:
On 05/22/2012 12:04 AM, Thomas Gleixner wrote:
The only justification for having the same layout as the actual
hardware is when you are going to map the memory into the guest space,
which is not the case
On Wed, May 23, 2012 at 04:48:46PM +0200, Ingo Molnar wrote:
there's just so many hours in the merge window, so you asked to be
flamed ...
I can handle flames just fine :) But I'll try to buffer x86 things up
until the window closes next time.
--
MST
--
To unsubscribe from this list: send the
On Wed, 23 May 2012, Avi Kivity wrote:
On 05/22/2012 08:26 PM, Thomas Gleixner wrote:
On Tue, 22 May 2012, Avi Kivity wrote:
On 05/22/2012 12:04 AM, Thomas Gleixner wrote:
The only justification for having the same layout as the actual
hardware is when you are going to map the memory
On 05/23/2012 08:14 AM, Michael S. Tsirkin wrote:
On Wed, May 23, 2012 at 04:48:46PM +0200, Ingo Molnar wrote:
there's just so many hours in the merge window, so you asked to be
flamed ...
I can handle flames just fine :) But I'll try to buffer x86 things up
until the window closes next
On 05/23/2012 11:37 AM, Thomas Gleixner wrote:
That works, but replaces one problem with another: now we have two
sources for the same data, and need to juggle between them depending on
register number (either synchronizing in both directions, or special
casing); so you're simplifying one
On Wed, 23 May 2012, Avi Kivity wrote:
On 05/23/2012 05:48 PM, Ingo Molnar wrote:
This is silly. Most of the time the kernel is advanced by
incremental patches. Sometimes it is advanced by minor or
major refactoring. It is never advanced by personal attacks
on contributors.
On Wed, May 23, 2012 at 10:10:27PM +0200, Thomas Gleixner wrote:
Replying on a still polite reminder with a sloppy I just took what's
there and implemeted the optimization which I was tasked with is even
more of an offense.
Ow. That 'not my fault' line was a joke.
--
MST
--
To unsubscribe
On Wed, 23 May 2012, H. Peter Anvin wrote:
On 05/23/2012 11:37 AM, Thomas Gleixner wrote:
That works, but replaces one problem with another: now we have two
sources for the same data, and need to juggle between them depending on
register number (either synchronizing in both directions,
On Wed, 23 May 2012, Michael S. Tsirkin wrote:
On Wed, May 23, 2012 at 10:10:27PM +0200, Thomas Gleixner wrote:
Replying on a still polite reminder with a sloppy I just took what's
there and implemeted the optimization which I was tasked with is even
more of an offense.
Ow. That 'not
On 05/22/2012 02:01 AM, Thomas Gleixner wrote:
Others are not my fault :)
Seriously, if Avi/Marcelo want to rewrite the ISR emulation
Interesting POV, really.
Did you ever notice that the kernel is a collaborative effort and not
controlled by Avi/Marcelo?
Did you ever notice that
On 05/22/2012 12:04 AM, Thomas Gleixner wrote:
+static u8 count_vectors(void *bitmap)
+{
+ u32 *word = bitmap;
+ int word_offset;
+ u8 count = 0;
+ for (word_offset = 0; word_offset MAX_APIC_VECTOR 5; ++word_offset)
+ count += hweight32(word[word_offset 2]);
On Tue, 22 May 2012, Avi Kivity wrote:
On 05/22/2012 12:04 AM, Thomas Gleixner wrote:
The only justification for having the same layout as the actual
hardware is when you are going to map the memory into the guest space,
which is not the case here.
The APIC page is in fact mapped to the
We perform ISR lookups twice: during interrupt
injection and on EOI. Typical workloads only have
a single bit set there. So we can avoid ISR scans by
1. counting bits as we set/clear them in ISR
2. if count is 1, caching the vector number
3. if count != 1, invalidating the cache
The real purpose
On Mon, May 21, 2012 at 07:37:27PM +0300, Michael S. Tsirkin wrote:
We perform ISR lookups twice: during interrupt
injection and on EOI. Typical workloads only have
a single bit set there. So we can avoid ISR scans by
1. counting bits as we set/clear them in ISR
2. if count is 1, caching the
On Mon, 21 May 2012, Michael S. Tsirkin wrote:
We perform ISR lookups twice: during interrupt
injection and on EOI. Typical workloads only have
a single bit set there. So we can avoid ISR scans by
1. counting bits as we set/clear them in ISR
2. if count is 1, caching the vector number
3. if
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
@@ -242,6 +262,25 @@ static inline void apic_clear_irr(int vec, struct
kvm_lapic *apic)
apic-irr_pending = true;
}
+static inline void apic_set_isr(int vec, struct kvm_lapic *apic)
+{
+ if
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
@@ -242,6 +262,25 @@ static inline void apic_clear_irr(int vec, struct
kvm_lapic *apic)
apic-irr_pending = true;
}
+static inline void apic_set_isr(int
On Tue, May 22, 2012 at 12:14:18AM +0200, Thomas Gleixner wrote:
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
@@ -242,6 +262,25 @@ static inline void apic_clear_irr(int vec, struct
kvm_lapic *apic)
Michael,
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Tue, May 22, 2012 at 12:14:18AM +0200, Thomas Gleixner wrote:
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
@@ -242,6 +262,25 @@ static inline void
On Tue, May 22, 2012 at 12:44:39AM +0200, Thomas Gleixner wrote:
Michael,
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Tue, May 22, 2012 at 12:14:18AM +0200, Thomas Gleixner wrote:
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Tue, May 22, 2012 at 12:14:18AM +0200, Thomas Gleixner wrote:
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
@@ -242,6 +262,25 @@ static inline void apic_clear_irr(int
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
On Mon, 21 May 2012, Michael S. Tsirkin wrote:
We perform ISR lookups twice: during interrupt
injection and on EOI. Typical workloads only have
a single bit set there. So we can avoid ISR scans by
1. counting bits as we
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Tue, May 22, 2012 at 12:14:18AM +0200, Thomas Gleixner wrote:
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
@@ -242,6 +262,25 @@ static inline void apic_clear_irr(int
On 05/21/2012 04:06 PM, Michael S. Tsirkin wrote:
I think the reason is __apic_read which now simply copies the registers
out to guest, this code will become less straight-forward if it's not
1:1.
It can still be 1:1, just drop the 12 bytes of completely useless
padding after each 32-bit
On Tue, 22 May 2012, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 11:04:25PM +0200, Thomas Gleixner wrote:
On Mon, 21 May 2012, Michael S. Tsirkin wrote:
+static u8 count_vectors(void *bitmap)
+{
+ u32 *word = bitmap;
+ int word_offset;
+ u8 count = 0;
+ for (word_offset
28 matches
Mail list logo
