All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 1/3 v2] Add Directed EOI support to APIC emulation
Date: Mon, 29 Jun 2009 12:52:28 +0300	[thread overview]
Message-ID: <20090629095228.GV20289@redhat.com> (raw)
In-Reply-To: <4A488E0C.7080207@redhat.com>

On Mon, Jun 29, 2009 at 12:49:00PM +0300, Avi Kivity wrote:
> On 06/29/2009 12:29 PM, Gleb Natapov wrote:
>> On Mon, Jun 29, 2009 at 12:18:28PM +0300, Avi Kivity wrote:
>>    
>>> On 06/28/2009 03:15 PM, Gleb Natapov wrote:
>>>      
>>>> Directed EOI is specified by x2APIC, but is available even when lapic is
>>>> in xAPIC mode.
>>>>
>>>>    #define APIC_LVT_NUM			6
>>>>    /* 14 is the version for Xeon and Pentium 8.4.8*/
>>>> -#define APIC_VERSION			(0x14UL | ((APIC_LVT_NUM - 1)<<   16))
>>>> +#define APIC_VERSION			(0x14UL | ((APIC_LVT_NUM - 1)<<   16) | \
>>>> +					 APIC_LVR_DIRECTED_EOI)
>>>>
>>>>        
>>> Better make that depend on the x2apic cpuid bit.
>>>
>>>      
>> Are you sure. It looks like this feature is independent from x2APIC. It just specified
>> by the same spec.
>>    
>
> We're changing something that the guests sees.  Suppose the guest has a  
> bug in directed EOI, just upgrading kvm will cause it to trigger.  If we  
> make it dependent on x2apic (or something else that needs to be selected  
> by the user), we maintain compatibility.
>
Yes, I thought about something else (not x2apic). But yet another command line
switch look like overkill.

>>>>    	case APIC_SPIV:
>>>> -		apic_set_reg(apic, APIC_SPIV, val&   0x3ff);
>>>> +		apic_set_reg(apic, APIC_SPIV, val&   0xfff);
>>>>    		if (!(val&   APIC_SPIV_APIC_ENABLED)) {
>>>>    			int i;
>>>>    			u32 lvt_val;
>>>>
>>>>        
>>> Confused, you're adding bits 10 and 11 while APIC_SPIV_DIRECTED_EOI is
>>> bit 12?
>>>      
>> For well behaved guests it doesn't matter :) And Intel keep changing
>> what reserved bits are in this register. Older doc says bit 9 is a Focus
>> Processor bit, x2APIC doc says bit 9 is registered. So what should we do
>> for bit 9?
>>    
>
> Let's make it a separate patch in case something blows.  I think you  
> need to allow bit 9 even if x2apic retroactively reserves it.
>
OK.

--
			Gleb.

  reply	other threads:[~2009-06-29  9:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-28 12:15 [PATCH 0/3 v2] x2APIC emulation for kvm Gleb Natapov
2009-06-28 12:15 ` [PATCH 1/3 v2] Add Directed EOI support to APIC emulation Gleb Natapov
2009-06-29  9:18   ` Avi Kivity
2009-06-29  9:29     ` Gleb Natapov
2009-06-29  9:49       ` Avi Kivity
2009-06-29  9:52         ` Gleb Natapov [this message]
2009-06-29 10:01           ` Avi Kivity
2009-06-28 12:15 ` [PATCH 2/3 v2] x2APIC interface to local apic Gleb Natapov
2009-06-29  9:42   ` Avi Kivity
2009-06-29  9:51     ` Gleb Natapov
2009-06-29  9:54       ` Avi Kivity
2009-06-28 12:15 ` [PATCH 3/3 v2] Add x2APIC support to qemu-kvm Gleb Natapov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090629095228.GV20289@redhat.com \
    --to=gleb@redhat.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.