From f2f722515135d95016f2d2ab55cc2aaf23d2fd80 Mon Sep 17 00:00:00 2001
From: Weidong Han [EMAIL PROTECTED]
Date: Sat, 27 Sep 2008 14:28:07 +0800
Subject: [PATCH] Support multiple device assignment to one guest
Current VT-d patches in kvm only support one device assignment to one
guest due to
Hi Thomas,
the patches of passthrough/VT-d on kvm.git are already checked in. With
Amit's userspace patches, you can assign device to guest. You can have a
try.
Randy (Weidong)
Thomas Fjellstrom wrote:
I'm very interested in being able to pass a few devices through to
kvm guests. I'm
On Saturday 27 September 2008, Han, Weidong wrote:
Hi Thomas,
the patches of passthrough/VT-d on kvm.git are already checked in. With
Amit's userspace patches, you can assign device to guest. You can have a
try.
Does that mean I need VT-d support in hardware? All I have to test with right
Thomas Fjellstrom wrote:
On Saturday 27 September 2008, Han, Weidong wrote:
Hi Thomas,
the patches of passthrough/VT-d on kvm.git are already checked in.
With Amit's userspace patches, you can assign device to guest. You
can have a try.
Does that mean I need VT-d support in hardware? All
On Saturday 27 September 2008, Han, Weidong wrote:
Thomas Fjellstrom wrote:
On Saturday 27 September 2008, Han, Weidong wrote:
Hi Thomas,
the patches of passthrough/VT-d on kvm.git are already checked in.
With Amit's userspace patches, you can assign device to guest. You
can have a
Greetings,
Following patches are intended to support SR-IOV capability in the Linux
kernel. With these patches, people can turn a PCI device with the capability
into multiple ones from software perspective, which can benefit KVM and achieve
other purposes such as QoS, security, etc.
[PATCH
Export some functions and move some macros from c file to header file.
Cc: Jesse Barnes [EMAIL PROTECTED]
Cc: Randy Dunlap [EMAIL PROTECTED]
Cc: Grant Grundler [EMAIL PROTECTED]
Cc: Alex Chiang [EMAIL PROTECTED]
Cc: Matthew Wilcox [EMAIL PROTECTED]
Cc: Roland Dreier [EMAIL PROTECTED]
Cc: Greg KH
Add Single Root I/O Virtualization (SR-IOV) support.
Cc: Jesse Barnes [EMAIL PROTECTED]
Cc: Randy Dunlap [EMAIL PROTECTED]
Cc: Grant Grundler [EMAIL PROTECTED]
Cc: Alex Chiang [EMAIL PROTECTED]
Cc: Matthew Wilcox [EMAIL PROTECTED]
Cc: Roland Dreier [EMAIL PROTECTED]
Cc: Greg KH [EMAIL PROTECTED]
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
Muli Ben-Yehuda wrote:
MMIO isn't just a register window. It may be an on-device buffer.
Unlikely, but ok.
It's unlikely in the same ways graphics cards are unlikely :)
With a multi-card setup, perhaps it is even reasonable for one card to
dma to another.
I strongly
Marcelo Tosatti wrote:
There's no need to increase the largepage shadow count when syncing
since there's no count decrement on unsync, only on destruction.
Applied, thanks.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To
Jes Sorensen wrote:
Hi,
Looking through the ia64 code I came across this little gem.
At some point someone added a new argument to hw/pc.c:cmos_init() named
'smp_cpus', and then passed in the global variable 'smp_cpus' as the
argument. This propagated through to the ia64 code as well.
I
Jes Sorensen wrote:
Hi,
Xiantao and I have agreed to reformat the ia64 related code so it
better matches the QEMU formatting style.
This patch has zero code change, it is solely reformatting.
It goes on top of the cmos_init() tidyup patch I sent out earlier today.
Applied, thanks. I got a
Jan Kiszka wrote:
As a workaround (or safety bag), is it imaginable to delay or deny VCPU
snapshots at not yet fully restorable points (like
GUEST_INTERRUPTIBILITY_INFO != 0)? Or stick-your-head-into-the-sand for now?
Head in sand. The points where we have interrupt shadows should be
Joerg Roedel wrote:
I had another possible idea for performance improvement here. Since we
only inject normal interrupts and exceptions (and not NMI and such) we
can patch clgi to cli and stgi to sti to save these two intercepts in
the guests vmrun path.
Any objections/problems with this?
Alexander Graf wrote:
Hmm yes, this is a problem. So this optimization will not work. We need
other ways to optimize :)
Well it would work for the KVM-in-KVM case, where we know that VMRUN
is always triggered with IF=1 and V_INTR=1. The only case that hack
fails is when we have IF=0 and
Alexander Graf wrote:
Is copying one page really that expensive? Is there any accelerated
function available for that that copies it with SSE or so? :-)
'rep movs' is supposed to be accelerated, doing cacheline-by-cacheline
copies (at least on Intel).
In any case the kernel memcpy()
[EMAIL PROTECTED] wrote:
Copying data in memory is always expensive because the accesses may miss
in the caches and data must be fetched from memory. As far as I know
this can be around 150 cycles per cache line.
When the copy is sequential, the processor will prefetch the data ahead
of
On Sat, Sep 27, 2008 at 04:27:44PM +0800, Zhao, Yu wrote:
Export some functions and move some macros from c file to header file.
That's absolutely not everything this patch does. You need to split
this into smaller pieces and explain what you're doing and why for each
of them.
diff --git
Yang, Sheng wrote:
I think we should do a little more than just write msr to update mtrr.
Intel SDM 10.11.8 MTRR consideration in MP Systems define the procedure to
modify MTRR msr in MP. Especially, step 4 enter no-fill cache mode(set CR0.CD
bit and clean NW bit), step 12 re-enabled the
Hi,
I have about the same problem, so excuse me for hijacking this thread.
My hardware consists of a 780g/SB700 Mainboard and a 4850e AMD CPU, and
I'm interested in forwarding a DVB-C tuner card to the guest. Maybe
some NICs later.
I tried and 'sort of' got it working with Amit's kernel and
On Sat, 27 Sep 2008, Avi Kivity wrote:
Yang, Sheng wrote:
I think we should do a little more than just write msr to update mtrr.
Intel SDM 10.11.8 MTRR consideration in MP Systems define the procedure to
modify MTRR msr in MP. Especially, step 4 enter no-fill cache mode(set
CR0.CD bit
On Saturday 27 September 2008, Jan C. Bernauer wrote:
Hi,
I have about the same problem, so excuse me for hijacking this thread.
My hardware consists of a 780g/SB700 Mainboard and a 4850e AMD CPU, and
I'm interested in forwarding a DVB-C tuner card to the guest. Maybe
some NICs later.
I
Thomas Fjellstrom wrote:
How did you manage to pull together those patches? They all seem so
old, and
won't likely apply cleanly to git head :(
Which patches do you mean? The patches for kvm?
There is a nice repository managed by Amit Shah:
Linux source:
On Saturday 27 September 2008, Jan C. Bernauer wrote:
Thomas Fjellstrom wrote:
So I've checked out both of those trees and used head, and kvm-userspace
is erroring out:
gcc -I. -I.. -I/root/kvm-amit-userspace/qemu/target-i386
-I/root/kvm-amit- userspace/qemu -MMD -MT qemu-kvm-x86.o -MP
Thomas Fjellstrom wrote:
that leaves me with:
/root/kvm-amit-userspace/qemu/../libkvm/libkvm.h:28: warning: âstruct
kvm_msr_entryâ declared inside parameter list
On Saturday 27 September 2008, Jan C. Bernauer wrote:
Thomas Fjellstrom wrote:
that leaves me with:
/root/kvm-amit-userspace/qemu/../libkvm/libkvm.h:28: warning: âstruct
kvm_msr_entryâ declared inside parameter list
/root/kvm-amit-userspace/qemu/../libkvm/libkvm.h:28: warning: its scope
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
On Saturday 27 September 2008 21:55:33 Zwane Mwaikambo wrote:
On Sat, 27 Sep 2008, Avi Kivity wrote:
Yang, Sheng wrote:
I think we should do a little more than just write msr to update mtrr.
Intel SDM 10.11.8 MTRR consideration in MP Systems define the
procedure to modify MTRR msr
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
Jan C. Bernauer wrote:
Hi,
I have about the same problem, so excuse me for hijacking this thread.
My hardware consists of a 780g/SB700 Mainboard and a 4850e AMD CPU, and
I'm interested in forwarding a DVB-C tuner card to the guest. Maybe
some NICs later.
I tried and 'sort of' got it working
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
41 matches
Mail list logo
