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,
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. T
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 d
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 unsubscri
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 cont
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 simplifyin
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 n
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
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 th
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 no
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 person
* Avi Kivity 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 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
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[
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 e
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;
> > >
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-b
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_cle
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
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_cle
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
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 voi
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)
> > > >
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 voi
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)
> > +{
> > +
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
>
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
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 o
28 matches
Mail list logo
