qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: James Sullivan <sullivan.james.f@gmail.com>
Cc: pbonzini@redhat.com, mst@redhat.com, qemu-devel@nongnu.org,
	jan.kiszka@siemens.com
Subject: Re: [Qemu-devel] [PATCH v2 RESEND 5/5] apic: Implement handling of RH=1 for MSI interrupt delivery
Date: Fri, 24 Apr 2015 14:41:07 +0200	[thread overview]
Message-ID: <20150424124106.GA1873@potion.brq.redhat.com> (raw)
In-Reply-To: <5539431B.4090405@gmail.com>

2015-04-23 13:08-0600, James Sullivan:
> On 04/23/2015 08:14 AM, Radim Krčmář wrote:
>> 2015-04-06 17:45-0600, James Sullivan:
>>> diff --git a/hw/intc/apic.c b/hw/intc/apic.c
>>> @@ -519,23 +521,27 @@ static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask,
>>> +            if (apic_match_dest(apic_iter, dest_mode, dest)) {
>>> +                if (msi_redir_hint) {
>> 
>> You could check for APIC_DM_LOWPRI here as well and save the
>> apic_lowest_prio() loop in patch [1/4].
>> LOWPRI would be delivered like FIXED.
> 
> I was considering doing that, saving the loop is a big plus. My concern
> was that it would change get_delivery_bitmask's semantics in a way that
> could be confusing (i.e. it is currently expected that the caller is
> responsible for doing arbitration after the fact, this would flip that
> responsibility).

Good concern!  In this case, I think it's ok to change semantics, as the
function is static.  All callers are going to be in this module and they
call apic_bus_deliver() right after apic_get_delivery_bitmask() now.

(It's not like we could break interrupt delivery with this change, only
 logging or some other meta-operation would be affected.)

>> (Btw. lowest priority has a lot of cases that are forbidden ...
>>  - in combination with physical broadcast
>>  - in combination with clustered logical broadcast
>>  - to invalid/disabled destinations
>> 
>>  These most likely won't work correctly in real hardware.
>>  Lowest priority is a bad concept for large systems, which is why Intel
>>  stopped implementing it.)
>> 
> 
> Checking for such illegal cases should probably happen in the delivery
> routines before we set the delivery bitmask (in apic_bus_deliver()?)

What we have now is fine.  I presented them to lift constraints that
might have prevented you from making different decisions;
software mustn't configure them, so we're free to do whatever.

(I think it would be better if they didn't work, but haven't read enough
 QEMU code to know what is the approach here.)

      reply	other threads:[~2015-04-24 12:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-06 23:45 [Qemu-devel] [PATCH v2 RESEND 0/5] apic: Implement MSI RH bit handling, lowpri IRQ James Sullivan
2015-04-06 23:45 ` [Qemu-devel] [PATCH v2 RESEND 1/5] apic: Implement LAPIC low priority arbitration functions James Sullivan
2015-04-23 13:49   ` Radim Krčmář
2015-04-23 18:34     ` James Sullivan
2015-04-24 12:27       ` Radim Krčmář
2015-04-06 23:45 ` [Qemu-devel] [PATCH v2 RESEND 2/5] apic: Implement low priority arbitration for IRQ delivery James Sullivan
2015-04-06 23:45 ` [Qemu-devel] [PATCH v2 RESEND 3/5] apic: Added helper function apic_match_dest, apic_match_[physical, logical]_dest James Sullivan
2015-04-06 23:45 ` [Qemu-devel] [PATCH v2 RESEND 4/5] apic: Set and pass in RH bit for MSI interrupts James Sullivan
2015-04-06 23:45 ` [Qemu-devel] [PATCH v2 RESEND 5/5] apic: Implement handling of RH=1 for MSI interrupt delivery James Sullivan
2015-04-23 14:14   ` Radim Krčmář
2015-04-23 19:08     ` James Sullivan
2015-04-24 12:41       ` Radim Krčmář [this message]

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=20150424124106.GA1873@potion.brq.redhat.com \
    --to=rkrcmar@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sullivan.james.f@gmail.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;
as well as URLs for NNTP newsgroup(s).