All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <levinsasha928@gmail.com>
To: Jan Kiszka <jan.kiszka@siemens.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 17:11:01 +0300	[thread overview]
Message-ID: <1314972661.31676.11.camel@lappy> (raw)
In-Reply-To: <4E60E193.1050804@siemens.com>

On Fri, 2011-09-02 at 16:00 +0200, Jan Kiszka wrote:
> 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."
> 

When RH=1 and DM=0 yes, but what happens when RH=1 and DM=1?

>From what I understand we need to select the processor running at the
lowest priority between the processors that are identified by the
destination ID:

"If RH is 1 and DM is 1, the Destination ID Field is interpreted as in
logical destination mode and the redirection is limited to only those
processors that are part of the logical group of processors based on the
processor's logical APIC ID and the Destination ID field in the
message."

> 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
> 

-- 

Sasha.


  reply	other threads:[~2011-09-02 14:11 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
2011-09-02 14:11           ` Sasha Levin [this message]
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=1314972661.31676.11.camel@lappy \
    --to=levinsasha928@gmail.com \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --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 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.