Yang, Sheng wrote:
You're right, I didn't think it through.
If there was a standard way to mask pci irqs, it might have worked, but
there isn't, unfortunately.
What if we got a way to mask pci irqs? We also have to unmask pci irq when
guest wrote EOI to vlapic(or at any other time).
On Sat, Sep 27, 2008 at 01:16:22PM +0300, Avi Kivity wrote:
Using MSI works around the issue nicely, since interrupts are no
longer shared. I imagine SR-IOV also fixes the issue.
SR-IOV mandates the use of either MSI or MSI-X for VFs.
Cheers,
Muli
--
The First Workshop on I/O Virtualization
On Wednesday 24 September 2008 17:51:24 Avi Kivity wrote:
Yang, Sheng wrote:
2. shared guest pci interrupts
That's a correctness issue. No matter how many interrupts we have, we
may have sharing issues. Of course with only three the issue is very
pressing since we will get sharing
On Wednesday 24 September 2008 16:38:35 Avi Kivity wrote:
Yang, Sheng wrote:
- Shared Interrupt support
I still don't know who would do this. It's very important for VT-d real
usable. If nobody interested in it, I would pick it up, but after Oct. 6
(after National Holiday in
Yang, Sheng wrote:
After check host shared interrupts situation, I got a question here:
If I understand correctly, current solution don't block host shared irq, just
come with the performance pentry. The penalty come with host disabled irq
line for a period. We have to wait guest to write
From:Avi Kivity
Sent: 2008年9月27日 17:50
Yang, Sheng wrote:
After check host shared interrupts situation, I got a question here:
If I understand correctly, current solution don't block host
shared irq, just
come with the performance pentry. The penalty come with host
disabled irq
line for a
Tian, Kevin wrote:
From:Avi Kivity
Sent: 2008年9月27日 17:50
Yang, Sheng wrote:
After check host shared interrupts situation, I got a
question here:
If I understand correctly, current solution don't block
host shared irq, just come with the performance pentry.
The penalty come with host
I don't see how this relates to shared guest interrupts.
Whatever you have on the host side, you still need to
support shared guest interrupts. The only way to avoid
the issue is by using MSI for the guest, and even then we
still have to support interrupt sharing since not all
guests have
From: Dong, Eddie
Sent: 2008年9月28日 10:04
Tian, Kevin wrote:
From:Avi Kivity
Sent: 2008年9月27日 17:50
Yang, Sheng wrote:
After check host shared interrupts situation, I got a
question here:
If I understand correctly, current solution don't block
host shared irq, just come with the
Tian, Kevin wrote:
If the guest fails to disable interrupts on a device that shares an
interrupt line with the host, the host will experience an interrupt
flood. Eventually the host will disable the host device as well.
This issue also exists on host side, that one misbehaved driver
Dong, Eddie wrote:
I don't see how this relates to shared guest interrupts.
Whatever you have on the host side, you still need to
support shared guest interrupts. The only way to avoid
the issue is by using MSI for the guest, and even then we
still have to support interrupt sharing since not
From: Avi Kivity [mailto:[EMAIL PROTECTED]
Sent: 2008年9月28日 12:23
There is no issue on the host, since all drivers operate on the same
trust level. A misbehaving driver on the host will take down the entire
system even without shared interrupts, by corrupting memory, not
releasing a lock, etc.
Tian, Kevin wrote:
No. Maybe the Neocleus polarity trick (which also reduces performance).
To my knowledge, Neocleus polarity trick can't solve this isolation
issue, which just provides one effecient way to track assertion/deassertion
transition on the irq line. For example, reverse
On Sunday 28 September 2008 13:04:06 Avi Kivity wrote:
Tian, Kevin wrote:
No. Maybe the Neocleus polarity trick (which also reduces performance).
To my knowledge, Neocleus polarity trick can't solve this isolation
issue, which just provides one effecient way to track
Avi Kivity wrote:
Dong, Eddie wrote:
I don't see how this relates to shared guest interrupts.
Whatever you have on the host side, you still need to
support shared guest interrupts. The only way to avoid
the issue is by using MSI for the guest, and even then
we still have to support
On Sunday 28 September 2008 13:04:06 Avi Kivity wrote:
Tian, Kevin wrote:
No. Maybe the Neocleus polarity trick (which also reduces performance).
To my knowledge, Neocleus polarity trick can't solve this isolation
issue, which just provides one effecient way to track
Hi all,
The initial passthrough/VT-d patches have been in kvm, it's time to
enhance it, and push them into 2.6.28.
Following is the remaining passthrough/VT-d tasks list:
- Multiple devices assignment (WIP)
- MSI support (WIP)
- MTRR/PAT support of EPT (WIP
On Wednesday 24 September 2008 14:15:15 Han, Weidong wrote:
Hi all,
The initial passthrough/VT-d patches have been in kvm, it's time to enhance
it, and push them into 2.6.28.
Some supplements:
Following is the remaining passthrough/VT-d tasks list:
- Multiple devices assignment
* On Wednesday 24 Sep 2008 13:21:25 Han, Weidong wrote:
Amit Shah wrote:
- Add dummy driver to hide/unbind passthrough device from
host kernel
This isn't needed; we currently don't assign the device to the guest
if we find that a driver is already loaded. I intend to change it to
Han, Weidong wrote:
Hi all,
The initial passthrough/VT-d patches have been in kvm, it's time to
enhance it, and push them into 2.6.28.
- Shared Interrupt support
Shared guest interrupts is a prerequisite for merging into mainline.
Without this, device assignment is useless in
Amit Shah wrote:
* On Wednesday 24 Sep 2008 13:21:25 Han, Weidong wrote:
Amit Shah wrote:
- Add dummy driver to hide/unbind passthrough device from
host kernel
This isn't needed; we currently don't assign the device to the guest
if we find that a driver is already loaded. I
Yang, Sheng wrote:
- MSI support (WIP)
- MTRR/PAT support of EPT (WIP)
- MTRR/PAT support of shadow (WIP)
- Basic FLR support (WIP)
Above four are my works. All of them work now. But more job should be done to
polish the patches. And the main part of
Han, Weidong wrote:
- Add dummy driver to hide/unbind passthrough device from host
kernel
Maybe this can be implemented at the modprobe/hotplug level.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm
On Wednesday 24 September 2008 16:34:22 Avi Kivity wrote:
Han, Weidong wrote:
Hi all,
The initial passthrough/VT-d patches have been in kvm, it's time to
enhance it, and push them into 2.6.28.
- Shared Interrupt support
Shared guest interrupts is a prerequisite for merging
On Wednesday 24 September 2008 16:38:35 Avi Kivity wrote:
Yang, Sheng wrote:
- MSI support (WIP)
- MTRR/PAT support of EPT (WIP)
- MTRR/PAT support of shadow (WIP)
- Basic FLR support (WIP)
Above four are my works. All of them work now. But more job
Amit Shah wrote:
I'd say we have about 3 weeks to get things in.
How do you figure? 2.6.26 was released July 13, we're more than 2.5
months later.
Furthermore, I'm not queueing untested patches for 2.6.28 at this time.
--
error compiling committee.c: too many arguments to function
--
Avi Kivity wrote:
Han, Weidong wrote:
- Add dummy driver to hide/unbind passthrough device from host
kernel
Maybe this can be implemented at the modprobe/hotplug level.
I think so.
Randy (Weidong)
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
Han, Weidong wrote:
We had some discussion on this few months ago. Currently, users need to
remove device driver before assignment. If there are more than one same
type devices, removing driver makes them cannot work at the same time,
even though user just want to assign one of them to guest.
Yang, Sheng wrote:
Shared guest interrupts is a prerequisite for merging into mainline.
Without this, device assignment is useless in anything but a benchmark
scenario. I won't push device assignment for 2.6.28 without it.
Shared host interrupts are a different matter; which one did you mean?
On Wednesday 24 September 2008 16:53:15 Avi Kivity wrote:
Yang, Sheng wrote:
Shared guest interrupts is a prerequisite for merging into mainline.
Without this, device assignment is useless in anything but a benchmark
scenario. I won't push device assignment for 2.6.28 without it.
Han, Weidong wrote:
Avi Kivity wrote:
Han, Weidong wrote:
- Add dummy driver to hide/unbind passthrough device from host
kernel
Maybe this can be implemented at the modprobe/hotplug level.
I think so.
I'm not sure now -- after I saw the point about a
Yang, Sheng wrote:
We only have three pci interrupts at this point (though this could be
easily extended); if you start the guest with a non-trivial number of
devices, you will have shared guest interrupts.
(of course, when I pointed this out during review, people said it could
be done later,
On Wednesday 24 September 2008 17:22:53 Avi Kivity wrote:
Yang, Sheng wrote:
We only have three pci interrupts at this point (though this could be
easily extended); if you start the guest with a non-trivial number of
devices, you will have shared guest interrupts.
(of course, when I
* On Wednesday 24 Sep 2008 14:08:14 Han, Weidong wrote:
Amit Shah wrote:
* On Wednesday 24 Sep 2008 13:21:25 Han, Weidong wrote:
Amit Shah wrote:
- Add dummy driver to hide/unbind passthrough device from
host kernel
This isn't needed; we currently don't assign the device to
* On Wednesday 24 Sep 2008 14:16:47 Avi Kivity wrote:
Amit Shah wrote:
I'd say we have about 3 weeks to get things in.
How do you figure? 2.6.26 was released July 13, we're more than 2.5
months later.
A week for 2.6.28 to open and two weeks for the rc1 window.
Furthermore, I'm not
Amit Shah wrote:
* On Wednesday 24 Sep 2008 14:16:47 Avi Kivity wrote:
Amit Shah wrote:
I'd say we have about 3 weeks to get things in.
How do you figure? 2.6.26 was released July 13, we're more than 2.5
months later.
A week for 2.6.28 to open and two weeks for the rc1
Amit Shah wrote:
* On Wednesday 24 Sep 2008 14:08:14 Han, Weidong wrote:
Amit Shah wrote:
* On Wednesday 24 Sep 2008 13:21:25 Han, Weidong wrote:
Amit Shah wrote:
- Add dummy driver to hide/unbind passthrough device from
host kernel
This isn't needed; we currently don't assign the
Avi Kivity wrote:
Amit Shah wrote:
* On Wednesday 24 Sep 2008 14:16:47 Avi Kivity wrote:
Amit Shah wrote:
I'd say we have about 3 weeks to get things in.
How do you figure? 2.6.26 was released July 13, we're more than 2.5
months later.
A week for 2.6.28 to open and two weeks for
Avi Kivity wrote:
Han, Weidong wrote:
- Add dummy driver to hide/unbind passthrough device from host
kernel
Maybe this can be implemented at the modprobe/hotplug level.
Wouldn't you just blacklist the devices in the host and call it a day?
Regards,
Anthony Liguori
--
To
Avi Kivity wrote:
Han, Weidong wrote:
Hi all,
The initial passthrough/VT-d patches have been in kvm,
it's time to enhance it, and push them into 2.6.28.
- Shared Interrupt support
Shared guest interrupts is a prerequisite for merging
into mainline. Without this, device
40 matches
Mail list logo
