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
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 wit
> 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
---
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
> 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
>> 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
On Wed, Jul 18, 2007 at 12:53:19PM +0300, Or Sagi wrote:
> Gentlepeople,
>
> We're currently working on PCI device pass-through support for KVM. In this
> model all physical hardware access to specific devices will be performed by
> the VM, and not by the host.
>
> In particular, this requires in
> 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.
Tricky inde
Gentlepeople,
We're currently working on PCI device pass-through support for KVM. In this
model all physical hardware access to specific devices will be performed by
the VM, and not by the host.
In particular, this requires interrupt handling to be done by the guest --
The host shouldn't load the
20 matches
Mail list logo
