From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Cc: keir@xen.org, suravee.suthikulpanit@amd.com, xen-devel@lists.xen.org
Subject: Re: [PATCH 1/4] x86/hvm: Centralize and simplify the RTC IRQ logic.
Date: Thu, 28 Mar 2013 19:57:18 +0000 [thread overview]
Message-ID: <CD7A511E.4EDB0%keir.xen@gmail.com> (raw)
In-Reply-To: <20130328153007.GM23950@ocelot.phlegethon.org>
On 28/03/2013 15:30, "Tim Deegan" <tim@xen.org> wrote:
>> And it further doesn't help that we don't even have
>> vioapic_irq_negative_edge() as counterpart to
>> vioapic_irq_positive_edge(), i.e. we're not even capable of truly
>> delivering an active low IRQ.
>
> I get the impression that the xen IRQ model doesn't actually include a
> concept of 'active high' vs 'active low', just 'asserted' or 'not
> asserted'. Keir?
Yes, this is correct. Possibly the naming of v[ioa]pic_irq_positive_edge is
unfortunate! Really it is indicating an asserting edge, regardless of
whether that edge is driving to a high or low voltage.
-- Keir
>> Which sadly makes me feel even more
>> nervous about your change here. Plus if IRQ8 is active low in our
>> emulation, then the if and else bodies would need to be switched
>> (which then wouldn't work because of deassert_irq() being too
>> simplistic).
>
> OK, so should I just respin without patch 1/4 and pretend I never saw
> any of this mess? :)
>
> Tim.
next prev parent reply other threads:[~2013-03-28 19:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 13:22 [PATCH 0/4] x86/hvm: RTC periodic timer adjustments Tim Deegan
2013-03-28 13:22 ` [PATCH 1/4] x86/hvm: Centralize and simplify the RTC IRQ logic Tim Deegan
2013-03-28 13:33 ` Andrew Cooper
2013-03-28 13:42 ` Tim Deegan
2013-03-28 13:49 ` Jan Beulich
2013-03-28 14:08 ` Tim Deegan
2013-03-28 14:22 ` Jan Beulich
2013-03-28 14:38 ` Tim Deegan
2013-03-28 15:19 ` Jan Beulich
2013-03-28 15:30 ` Tim Deegan
2013-03-28 15:41 ` Jan Beulich
2013-03-28 19:57 ` Keir Fraser [this message]
2013-03-28 13:22 ` [PATCH 2/4] x86/hvm: Run the RTC periodic timer on a consistent time series Tim Deegan
2013-03-28 13:27 ` Keir Fraser
2013-03-28 13:22 ` [PATCH 3/4] x86/hvm: Avoid needlessly resetting the periodic timer Tim Deegan
2013-03-28 13:41 ` Jan Beulich
2013-03-28 13:58 ` Tim Deegan
2013-03-28 13:22 ` [PATCH 4/4] x86/hvm: Let the guest miss a few ticks before resetting the timer Tim Deegan
2013-03-28 13:53 ` Jan Beulich
2013-03-28 14:42 ` Tim Deegan
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=CD7A511E.4EDB0%keir.xen@gmail.com \
--to=keir.xen@gmail.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=suravee.suthikulpanit@amd.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.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.