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
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.
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
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
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
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
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 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.
Well with
The problem you're having is essentially the same as the user-level
interrupt handler problem I've been dealing with for ages.
The basic rule is: don't share interrupts between devices on the host
and devices in the guest. But you *can* share interrupts between
devices in a single guest.
If
> 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
> - 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
>> >> 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
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.
> >>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
>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
> 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
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
>> 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.
>
> 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
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
> 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
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 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
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
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
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 indeed.
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
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
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 irq
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.
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 indeed.
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 this may
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
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
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 irq.
The guest will be released
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.
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.
The guest will be released right
- 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 is
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 this
The problem you're having is essentially the same as the user-level
interrupt handler problem I've been dealing with for ages.
The basic rule is: don't share interrupts between devices on the host
and devices in the guest. But you *can* share interrupts between
devices in a single guest.
If
42 matches
Mail list logo
