From: Jan Kiszka <jan.kiszka@siemens.com>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Avi Kivity <avi@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Gleb Natapov <gleb@redhat.com>,
"Tian, Kevin" <kevin.tian@intel.com>
Subject: Re: [PATCH v2] KVM: Implement support for the RH bit
Date: Fri, 02 Sep 2011 16:00:51 +0200 [thread overview]
Message-ID: <4E60E193.1050804@siemens.com> (raw)
In-Reply-To: <1314969237.31676.4.camel@lappy>
On 2011-09-02 15:13, Sasha Levin wrote:
> On Fri, 2011-09-02 at 14:11 +0200, Jan Kiszka wrote:
>> On 2011-09-02 13:36, Jan Kiszka wrote:
>>> On 2011-09-02 13:27, Jan Kiszka wrote:
>>>> On 2011-09-02 09:48, Sasha Levin wrote:
>>>>> The RH bit exists in the message address register (lower 32 bits of
>>>>> the address).
>>>>>
>>>>> The bit indicates whether the message should go to the processor which was
>>>>> indicated in the destination ID bits, or whether it should go to the
>>>>> processor running at the lowest priority.
>>>>>
>>>>> Cc: Avi Kivity <avi@redhat.com>
>>>>> Cc: Marcelo Tosatti <mtosatti@redhat.com>
>>>>> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
>>>>> ---
>>>>> virt/kvm/irq_comm.c | 17 ++++++++++++++++-
>>>>> 1 files changed, 16 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
>>>>> index 9f614b4..0ba3a3d 100644
>>>>> --- a/virt/kvm/irq_comm.c
>>>>> +++ b/virt/kvm/irq_comm.c
>>>>> @@ -134,7 +134,22 @@ int kvm_set_msi(struct kvm_kernel_irq_routing_entry *e,
>>>>> irq.level = 1;
>>>>> irq.shorthand = 0;
>>>>>
>>>>> - /* TODO Deal with RH bit of MSI message address */
>>>>> + /*
>>>>> + * If the RH bit is set, we'll deliver to the processor running
>>>>> + * at the lowest priority.
>>>>> + */
>>>>> + if (e->msi.address_lo & MSI_ADDR_REDIRECTION_LOWPRI) {
>>>>> + irq.delivery_mode = MSI_DATA_DELIVERY_LOWPRI;
>>>>> + } else {
>>>>> + /*
>>>>> + * If the RH bit is not set, we'll deliver to the specific
>>>>> + * processor mentioned in destination ID, and ignore the DM
>>>>> + * bit.
>>>>> + */
>>>>> + irq.dest_mode = MSI_ADDR_DEST_MODE_PHYSICAL;
>>>>> + irq.delivery_mode = MSI_DATA_DELIVERY_FIXED;
>>>>> + }
>>>>> +
>>>>> return kvm_irq_delivery_to_apic(kvm, NULL, &irq);
>>>>> }
>>>>>
>>>>
>>>> Do you happen have a kvm unit test for this? Or how did you validate the
>>>> change? It doesn't look incorrect to me, I'd just like to check it QEMU
>>>> as well which apparently already has the logic above but also some
>>>> contradictory comment.
>>>
>>> Err, no, QEMU does not have this logic, it also ignores RH.
>>>
>>> But the above bits make "irq.delivery_mode = e->msi.data & 0x700"
>>> pointless. And that strongly suggests something is still wrong.
>>
>> I tend to believe that this is what the spec tries to tell us:
>>
>> diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
>> index 9f614b4..b72f77a 100644
>> --- a/virt/kvm/irq_comm.c
>> +++ b/virt/kvm/irq_comm.c
>> @@ -128,7 +128,8 @@ int kvm_set_msi(struct kvm_kernel_irq_routing_entry *e,
>> MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
>> irq.vector = (e->msi.data &
>> MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
>> - irq.dest_mode = (1 << MSI_ADDR_DEST_MODE_SHIFT) & e->msi.address_lo;
>> + irq.dest_mode = ((e->msi.address_lo & MSI_ADDR_DEST_MODE_LOGICAL) &&
>> + (e->msi.address_lo & MSI_ADDR_REDIRECTION_LOWPRI));
>> irq.trig_mode = (1 << MSI_DATA_TRIGGER_SHIFT) & e->msi.data;
>> irq.delivery_mode = e->msi.data & 0x700;
>> irq.level = 1;
>>
>> ie. the DM flag is only relevant if RH is set, and RH==0 is equivalent
>> to RH==1 && DH==0.
>
> Thing is, the spec specifically states that RH==1 should deliver to
> lowest priority - even though it doesn't state whats the relationship
> between delivery mode and RH bit.
The spec says "When RH is 1 and the physical destination mode is used
[DM=0], the Destination ID field must not be set to 0xFF; it must point
to a processor that is present and enabled to receive the interrupt."
As far as I understand, there is no "lowest prio" in the setup RH=1/DM=0.
I've cc'ed Kevin who just worked on the APIC model. Maybe he can provide
some authoritative answer or dig it up @Intel.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2011-09-02 14:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-02 7:48 [PATCH v2] KVM: Implement support for the RH bit Sasha Levin
2011-09-02 11:27 ` Jan Kiszka
2011-09-02 11:36 ` Jan Kiszka
2011-09-02 12:11 ` Jan Kiszka
2011-09-02 13:13 ` Sasha Levin
2011-09-02 14:00 ` Jan Kiszka [this message]
2011-09-02 14:11 ` Sasha Levin
2011-09-02 14:25 ` Jan Kiszka
2011-09-02 14:30 ` Sasha Levin
2011-09-02 14:36 ` Jan Kiszka
2011-09-02 14:44 ` Gleb Natapov
2011-09-02 14:52 ` Jan Kiszka
2011-09-02 15:03 ` Gleb Natapov
2011-09-02 12:25 ` Gleb Natapov
2011-09-02 13:00 ` Jan Kiszka
2011-09-02 14:22 ` 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=4E60E193.1050804@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=levinsasha928@gmail.com \
--cc=mtosatti@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox