Hi!
I guess this will also allow UIO to work without _any_ kernel parts,
with only slight performance penalty in 'almost-never-happens'
deadlock case?
(Greg, details are below, and better description is in the lkml
thread).
Pavel
> > - Our
On Thu, Jul 19, 2007 at 04:38:09PM +0300, Avi Kivity wrote:
> Looking at two random servers here and a desktop, interrupts are
> unshared except for usb. A laptop was not so lucky. So "no chance" is
> a bit extreme.
>
> I agree it's far from optimal, but it is less limited than you imply.
Wel
Lennart Sorensen wrote:
On Thu, Jul 19, 2007 at 12:23:24PM +0300, Avi Kivity wrote:
No, it means disallowing pci devices that use shared irqs, and allowing
pci devices that use non-shared irqs.
Most machiens I see today have almost no chance of having PCI devices
without shared IRQs.
On Thu, Jul 19, 2007 at 12:23:24PM +0300, Avi Kivity wrote:
> No, it means disallowing pci devices that use shared irqs, and allowing
> pci devices that use non-shared irqs.
Most machiens I see today have almost no chance of having PCI devices
without shared IRQs. This probably means any impleme
Lennart Sorensen wrote:
On Wed, Jul 18, 2007 at 07:46:13PM +0300, Avi Kivity wrote:
IMO the only reasonable solution is to disallow interrupt forwarding
with shared irqs. If someone later comes up with a bright idea, we can
implement it. Otherwise the problem will solve itself with hardware
> Hope it should work like the following [Please correct me if I'm
> wrong]:
> - Make the device the last irqaction in the list
> - Our dummy handler will always return IRQ_HANDLED in case any other
> previous
> irqaction did not return such. It will also issue the timer and mask
> the irq in th
> - Make the device the last irqaction in the list
> - Our dummy handler will always return IRQ_HANDLED in case any other
> previous
> irqaction did not return such. It will also issue the timer and mask
> the irq in this case.
Ok
> btw, if I'm not mistaken only after bad 99900/10 the irq
>> >> Guest0 - blocked on I/O
>> >>
>> >> IRQ14 from your hardware
>> >> Block IRQ14
>> >> Sent to guest (guest is blocked)
>> >>
>> >> IRQ14 from hard disk
>> >> Ignored (as blocked)
>> >>
>>
>>
>> But now the timer will pop and the hard disk will get its
On Wed, Jul 18, 2007 at 07:46:13PM +0300, Avi Kivity wrote:
> IMO the only reasonable solution is to disallow interrupt forwarding
> with shared irqs. If someone later comes up with a bright idea, we can
> implement it. Otherwise the problem will solve itself with hardware
> moving to msi.
Disal
> >>Guest0 - blocked on I/O
> >>
> >>IRQ14 from your hardware
> >>Block IRQ14
> >>Sent to guest (guest is blocked)
> >>
> >>IRQ14 from hard disk
> >>Ignored (as blocked)
> >>
>
>
> But now the timer will pop and the hard disk will get its irq
>Alan Cox wrote:
>>> What if we will force the specific device to the end of the list.
>Once
>>> IRQ_NONE was returned by the other devices, we will mask the irq,
>>> forward the irq to the guest, issue a timer for 1msec. Motivation:
>>> 1msec is long enough for the guest to ack the irq + host unma
> Hotplug is user-controllable, so if the user refrains from adding pci
> devices after assigning a device to the guest, it should work. I think
> that USB interrupts are assigned to the controller, not the device, so
> USB hotplug can be ruled out.
Cardbus is more problematic.
Alan
-
To unsubsc
Alan Cox wrote:
>> IMO the only reasonable solution is to disallow interrupt forwarding
>> with shared irqs. If someone later comes up with a bright idea, we can
>>
>
> Which means you are back to ISA bus devices. Even checking if an IRQ is
> currently unshared isn't simple as with hotplug th
>> In particular, this requires interrupt handling to be done by the
>guest --
>> The host shouldn't load the corresponding device driver or otherwise
>access
>> the device. Since the host kernel is not aware of the device
semantics
>it
>> cannot acknowledge the interrupt at the device level.
>
>Tr
> IMO the only reasonable solution is to disallow interrupt forwarding
> with shared irqs. If someone later comes up with a bright idea, we can
Which means you are back to ISA bus devices. Even checking if an IRQ is
currently unshared isn't simple as with hotplug this may change.
> implement it.
Alan Cox wrote:
>> What if we will force the specific device to the end of the list. Once
>> IRQ_NONE was returned by the other devices, we will mask the irq,
>> forward the irq to the guest, issue a timer for 1msec. Motivation:
>> 1msec is long enough for the guest to ack the irq + host unmask the
> What if we will force the specific device to the end of the list. Once
> IRQ_NONE was returned by the other devices, we will mask the irq,
> forward the irq to the guest, issue a timer for 1msec. Motivation:
> 1msec is long enough for the guest to ack the irq + host unmask the irq
It makes no di
17 matches
Mail list logo
