[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest
From: |
Gabriel L. Somlo |
Subject: |
Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest |
Date: |
Mon, 17 Feb 2014 14:38:09 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Feb 17, 2014 at 07:06:11PM +0100, Paolo Bonzini wrote:
> Il 17/02/2014 19:01, Gabriel L. Somlo ha scritto:
> >On Mon, Feb 17, 2014 at 12:57:00PM -0500, Gabriel L. Somlo wrote:
> >>On Sun, Feb 16, 2014 at 06:23:11PM +0200, Michael S. Tsirkin wrote:
> >>>Well there is a bigger issue: any interrupt with
> >>>multiple sources is broken.
> >>>
> >>>__kvm_irq_line_state does a logical OR of all sources,
> >>>before XOR with polarity.
> >>>
> >>>This makes no sense if polarity is active low.
> >>
> >>So, do you think something like this would make sense, to address
> >>active-low polarity in __kvm_irq_line_state ?
> >>(this would be independent of the subsequent xor in
> >>kvm_ioapic_set_irq()):
> >
> >- return !!(*irq_state);
> >+ if (polarity) {
> >+ /* Logical AND for level trig interrupt, active-low */
> >+ return !~(*irq_state);
>
> This is ~*irq_state == 0, i.e. *irq_state == ~0.
>
> What if high-order bits of *irq_state are never used? That is, do
> you need to consider the maximum valid irq_source_id too?
Oh, I think I'm starting to comprehend the problem here. The bits of
"*irq_state" are indexed by "irq_source_id", which is dynamically
assigned by kvm_request_irq_source_id().
So, doing the OR thing when assuming always-active-high makes
sense. Doing AND based on an active-low assumption doesn't make
sense, because there could ALWAYS be 0 bits that just weren't
allocated (yet), and I'm having trouble imagining how I'd keep
track of where the current allocation boundary is in a sane way :)
Which I *think* was Michael's original point...
--Gabriel
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest, (continued)
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest, Alexander Graf, 2014/02/14
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest, Gabriel L. Somlo, 2014/02/14
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest, Alexander Graf, 2014/02/14
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest, Michael S. Tsirkin, 2014/02/16
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest, Michael S. Tsirkin, 2014/02/16
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest, Alex Williamson, 2014/02/16
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest, Michael S. Tsirkin, 2014/02/16
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest, Gabriel L. Somlo, 2014/02/17
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest, Gabriel L. Somlo, 2014/02/17
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest, Paolo Bonzini, 2014/02/17
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest,
Gabriel L. Somlo <=
- Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest, Gabriel L. Somlo, 2014/02/17
- [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity, Michael S. Tsirkin, 2014/02/27
- Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity, Gabriel L. Somlo, 2014/02/27
- Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity, Paolo Bonzini, 2014/02/27
- Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity, Gabriel L. Somlo, 2014/02/27
- Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity, Paolo Bonzini, 2014/02/27
- [Qemu-devel] [RFC PATCH v2] kvm: x86: ignore ioapic polarity, Gabriel L. Somlo, 2014/02/27
- [Qemu-devel] [RFC PATCH] qemu: x86: ignore ioapic polarity, Gabriel L. Somlo, 2014/02/28
- [Qemu-devel] [RFC PATCH v2] qemu: x86: ignore ioapic polarity, Gabriel L. Somlo, 2014/02/28
- [Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11, Gabriel L. Somlo, 2014/02/28