Any comments on the patchset? Thanks.
Regards,
Weidong
Han, Weidong wrote:
> Support source-id checking for interrupt remapping, and then
> isolates interrupts for guests/VMs with assigned devices.
>
> Eric raised pci rebalance issue with VT-d. Yes, it's an issue now.
> L
Paul Brook wrote:
> On Monday 08 June 2009, Weidong Han wrote:
>> When hot remove an assigned device, segmentation fault was triggered
>> by qemu_free(&pci_dev->qdev) in pci_unregister_device().
>> pci_register_device() doesn't initialize or set pci_dev->qdev. For an
>> assigned device, qdev variab
Gerd Hoffmann wrote:
> On 06/09/09 16:51, Paul Brook wrote:
>> On Tuesday 09 June 2009, Han, Weidong wrote:
>>> Paul Brook wrote:
>>>> On Monday 08 June 2009, Weidong Han wrote:
>>>>> When hot remove an assigned device, segmentation fault was
&g
Avi Kivity wrote:
> Han, Weidong wrote:
>>
>> -int pci_unregister_device(PCIDevice *pci_dev)
>> +int pci_unregister_device(PCIDevice *pci_dev, int assigned) {
>> int ret = 0;
>>
>> @@ -377,7 +377,11 @@ int pci_unregister_device(PCIDevice *pci_d
Gerd Hoffmann wrote:
> On 06/10/09 10:31, Han, Weidong wrote:
>> Avi Kivity wrote:
>>> Can you check pci_dev->qdev instead of assigned? A little less
>>> ugly.
>>
>> I tried to find an easy and clean way to check it, but I found the
>> memb
Subash Kalbarga wrote:
> Hi
>
> I am using kvm-86 on 2.6.28 and I am able to pass through most of my
> PCI devices successfully. However, I do not see even the KVM BIOS
> output if I pass through my VGA adapter. I am doing -vga none,
> -nographic and -pcidevice host=xx:yy.z
>
>
> Should I expe
Avi Kivity wrote:
> On 06/30/2009 09:16 AM, Han, Weidong wrote:
>> Subash Kalbarga wrote:
>>
>>> Hi
>>>
>>> I am using kvm-86 on 2.6.28 and I am able to pass through most of my
>>> PCI devices successfully. However, I do not see even the KVM BIO
Michael Tokarev wrote:
> Han, Weidong wrote:
> []
>>>> Currently VGA pass-through is not supported in KVM. It needs much
>>>> work to support it.
>>>>
>>> What does it need?
>>>
>>> Here's what I know of:
>>>
&
Michael Tokarev wrote:
> Han, Weidong wrote:
>> Michael Tokarev wrote:
> []
>>> But how about using it as a "secondary" video card? Like, I can
>>> plug another add-on vga card into a free PCI slot and tell X to
>>> use that one i
Subash Kalbarga wrote:
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of Subash Kalbarga
> Sent: Thursday, July 09, 2009 12:51 PM
> To: kvm@vger.kernel.org
> Subject:
>
> Hi
>
> I find that the HOW-TO for VT-d pass through on linux-kv
Carl-Daniel Hailfinger wrote:
> Hi,
>
> I want to trace the PCI device accesses (config space, I/O ports,
> memory BARs) of a DOS application (EEPROM flasher) and it seems KVM
> can help with this.
> The current plan is to install KVM, use FreeDOS as a guest, activate
> passthrough for the PCI dev
Wolfgang Nothdurft wrote:
> Hi,
>
> what limits does kvm have with device assignment and vt-d enabled.
>
> - Is it possible to assign pci devices behind the same pci bridge to
> different guests?
For devices behind conventional PCI bridges, the source-id in the DMA requests
is the requester-id
nathan binkert wrote:
Currently VGA pass-through is not supported in KVM. It needs much
work to support it.
>>>
>>> Here's what I know of:
>>>
>>> - load the vga bios at 0xc
>>> - implement whatever main bios interfaces the vga vios expects
>>> - pass through the vga I/O ports
>>>
Yang, Sheng wrote:
> On Thursday 21 August 2008 00:43:22 Muli Ben-Yehuda wrote:
>> On Wed, Aug 20, 2008 at 06:04:26PM +0300, Avi Kivity wrote:
>>> Other noteworthy changes: speedups of both virtio-net and qcow2
>>> with cache=off. Two important works-in-progress: device
>>> assignment (not usable
Avi Kivity wrote:
> Amit Shah wrote:
>>> That only detects if the headers have the flag, not if the kernel
>>> actually supports it (and whether there is an iommu in the host).
>>> We need run-time detection.
>>>
>>
>> Which means we expose KVM_CAP_IOMMU only if one was detected?
>
> Yes.
>
>
Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Amit Shah wrote:
>>
>>> * On Tuesday 26 Aug 2008 15:58:42 Zhang, Xiantao wrote:
>>>
Maybe vtd.c should be put @ virt/kvm so that ia64 can share it to
avoid future code move.
>>> As of now, device assignment resides inside the x86 direc
Hi Gregor,
You'd better set the loglevel=8 to print debug information. Can you also
try linux guest?
Randy (Weidong)
Yang, Sheng wrote:
> On Tuesday 02 September 2008 16:44:18 [EMAIL PROTECTED] wrote:
>> Hi,
>>
>> i am interested in the use of the new VT-d hardware feature.
>> My Dell-PC "OPTIP
After I destroyed the guest by clicking qume "x" button, and assigned
the same assigned device to guest, I met this same issue. The reason is
the assigned device doesn't exit normally, then its status is incorrect.
Doing FLR should solve the issue. We will add FLR mechanism for it
later.
For Grego
I think the assigned NIC shares IRQ with other devices. You can verify
it at request_irq() in kvm_vm_ioctl_assign_irq() (arch/x86/kvm/x86.c).
"assigned_dev_update_irq: Input/output error" should be caused by
request_irq() failure. In my machine, add-on NIC shares IRQ with usb.
You can check it in /
ready be applied. )
>>
>> No patches have already been applied to any tree. You'll definitely
>> have to apply the 1/2 patch as well.
>
> Ok. On both PCI-Cards (1) APCI1500 Signal processing controller and
> (2) Realtek NIC
> the IRQ is shared with my USB-UHCI-Contro
Amit Shah wrote:
> There are a couple of things here that might need some error handling:
>
> * On Tuesday 26 August 2008 14:25:35 Amit Shah wrote:
>> From: Ben-Ami Yassour <[EMAIL PROTECTED]>
>>
>> Based on a patch by: Kay, Allen M <[EMAIL PROTECTED]>
>>
>> This patch enables PCI device assignm
The following two patches contain VT-d support for device assignment for
KVM guests.
The first patch contains the changes that are required to the generic
VT-d code.
The second patch contains the changes to KVM.
Mark has acked on these two patches. Since the last send, I've updated
the first pat
From: Ben-Ami Yassour <[EMAIL PROTECTED]>
Based on a patch by: Kay, Allen M <[EMAIL PROTECTED]>
This patch enables PCI device assignment based on VT-d support.
When a device is assigned to the guest, the guest memory is pinned and
the mapping is updated in the VT-d IOMMU.
[Amit: Expose KVM_CAP_I
Amit,
Thanks for your quick fixing.
Randy (Weidong)
Amit Shah wrote:
> * On Tuesday 09 September 2008 19:21:20 Han, Weidong wrote:
>
>> +static int kvm_iommu_map_memslots(struct kvm *kvm) +{
>> +int i, rc;
>> +
>> +down_read(&kvm->slots_lock);
>
Avi Kivity wrote:
> Amit Shah wrote:
>> From: Kay, Allen M <[EMAIL PROTECTED]>
>>
>> This patch extends the VT-d driver to support KVM
>>
>> [Ben: fixed memory pinning]
>>
>> Signed-off-by: Kay, Allen M <[EMAIL PROTECTED]>
>> Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
>> Signed-off-by: Ben-A
This patch only can work on x86, it breaks build on other architectures.
It is caused by kvm_irq_ack_notifier and kvm_assigned_dev_kernel are
defined under x86, while they are always used in
include/linux/kvm_host.h whether CONFIG_DMAR is set or not. I move these
two definitions to include/linux/kv
This compatibility code for intel_iommu makes VT-d cannot work in
current code (version < 2.6.28), due to intel_iommu_found() returns 0.
Why add this limitation?
Randy (Weidong)
Mike Day wrote:
> Compatibility code for intel_iommu no longer needed when
> dependency on CONFIG_DMAR removed from kvm
Mike,
I saw your patch. It's good.
Randy (Weidong)
Mike Day wrote:
> On 18/09/08 22:07 +0800, Han, Weidong wrote:
> The previous patch I sent out (for the kvm kernel tree) changes
> intel-iommu.h so this compatibility code is no longer needed.
>
> Mike
>
>>
>From 9d8e927a937ff7c9fa2bcc3aa5359e73990658f0 Mon Sep 17 00:00:00 2001
From: Weidong Han <[EMAIL PROTECTED]>
Date: Fri, 19 Sep 2008 14:04:52 +0800
Subject: [PATCH] Fix iommu map page for mmio pages
Don't need to map mmio pages for iommu. When find mmio pages in
kvm_iommu_map_pages(), don't map th
Amit,
There are a few format issues in your patch, and this patch doesn't
work.
Flag KVM_DEV_ASSIGN_ENABLE_IOMMU is not set correctly. My comment
inline.
Amit Shah wrote:
> +
> +static AssignedDevice *register_real_device(PCIBus *e_bus,
> + const char *e
Currently "#include " is not needed in
virt/kvm/kvm_main.c. What's more, this inclusion may result in
compilation error in other architecture.
Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
---
virt/kvm/kvm_main.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/virt/kvm/k
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)
- MTR
Amit Shah wrote:
> * On Wednesday 24 Sep 2008 12:01:12 Yang, Sheng wrote:
>> On Wednesday 24 September 2008 14:15:15 Han, Weidong wrote:
>
>> Another thing is we would send out/update above patches before Sept.
>> 28, and hope they can picked by 2.6.28 merge window.
>
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 assi
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
Avi Kivity wrote:
> Han, Weidong wrote:
>> Currently "#include " is not needed in
>> virt/kvm/kvm_main.c. What's more, this inclusion may result in
>> compilation error in other architecture.
>>
>>
>
> Applied, but please also fix intel
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
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.
Avi Kivity wrote:
> Han, Weidong wrote:
>> Don't need to map mmio pages for iommu. When find mmio pages in
>> kvm_iommu_map_pages(), don't map them, and shouldn't return error
>> due to it's not an error. If return error (such as -EINVAL), device
>>
Avi Kivity wrote:
> Han, Weidong wrote:
>> Avi Kivity wrote:
>>
>>> Han, Weidong wrote:
>>>
>>>> Don't need to map mmio pages for iommu. When find mmio pages in
>>>> kvm_iommu_map_pages(), don't map them, and shouldn't retu
Avi and Anthony,
I will resend the patch soon. Thanks.
Randy (Weidong)
Anthony Liguori wrote:
> Avi Kivity wrote:
>> Han, Weidong wrote:
>>> Is it possible DMA into an mmio page?
>>
>> I don't see why not.
>
> Yeah, it is. I mentioned this a long ti
>From 61028d958dc7c57ee02de32ea89b025dccb9650d Mon Sep 17 00:00:00 2001
From: Weidong Han <[EMAIL PROTECTED]>
Date: Thu, 25 Sep 2008 23:32:02 +0800
Subject: [PATCH] Map mmio pages into VT-d page table
Assigned device could DMA to mmio pages, so also need to map mmio pages
into VT-d page table.
Si
>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 dm
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 wonderi
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.
>
Muli Ben-Yehuda wrote:
> On Sat, Sep 27, 2008 at 02:28:03PM +0800, Han, Weidong wrote:
>>> From f2f722515135d95016f2d2ab55cc2aaf23d2fd80 Mon Sep 17 00:00:00
>>> 2001
>> From: Weidong Han <[EMAIL PROTECTED]>
>> Date: Sat, 27 Sep 2008 14:28:07 +0800
>
Muli Ben-Yehuda wrote:
> On Sat, Sep 27, 2008 at 02:28:03PM +0800, Han, Weidong wrote:
>>> From f2f722515135d95016f2d2ab55cc2aaf23d2fd80 Mon Sep 17 00:00:00
>>> 2001
>> From: Weidong Han <[EMAIL PROTECTED]>
>> Date: Sat, 27 Sep 2008 14:28:07 +0800
>
[Rebased the patch due to my mmio's patch (commit: 0d679782) was checked
in]
>From 9e68fc762358cc44cfec3968ac5ec65324ce04d7 Mon Sep 17 00:00:00 2001
From: Weidong Han <[EMAIL PROTECTED]>
Date: Mon, 6 Oct 2008 14:02:18 +0800
Subject: [PATCH] Support multiple device assignment to one guest
Current
Avi Kivity wrote:
> Han, Weidong wrote:
>> [Rebased the patch due to my mmio's patch (commit: 0d679782) was
>> checked in]
>>
>> From 9e68fc762358cc44cfec3968ac5ec65324ce04d7 Mon Sep 17 00:00:00
>> 2001 From: Weidong Han <[EMAIL PROTECTED]>
>&g
Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Hi, Avi
>> I have rebased the patchset according to your comments, it can
>> be applied to current tip of kvm.git. Please review again and apply
>> if no other concerns. Thanks! Xiantao
>> [PATCH 1/8] kvm/vt-d: Moving vtd.c from arch/x86/kvm/ to vi
Zhang, Xiantao wrote:
> Han, Weidong wrote:
>> Avi Kivity wrote:
>>> Zhang, Xiantao wrote:
>>>> Hi, Avi
>>>>I have rebased the patchset according to your comments, it can
>>>> be applied to current tip of kvm.git. Please review again
Avi Kivity wrote:
> Han, Weidong wrote:
>>> Oh, I see it now. Different devices may need to go under different
>>> iommus.
>>>
>>> This really feels like it should be handled by the iommu API. Users
>>> shouldn't need to bother with it.
>
I added pass-through/VT-d todo list on KVM TODO page:
http://kvm.qumranet.com/kvmwiki/TODO.
If you are interested, pls pick them up and keep community informed.
Thanks.
Regards,
Weidong
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
Avi Kivity wrote:
> Han, Weidong wrote:
>>> If we devolve this to the iommu API, the same io page table can be
>>> shared by all iommus, so long as they all use the same page table
>>> format.
>>>
>>
>> I don't understand how to hand
Avi Kivity wrote:
> Han, Weidong wrote:
>>>
>>> I don't want then to share dmar_domains (these are implementation
>>> details anyway), just io page tables.
>>>
>>>
>>> kvm ---> something (owns io page table) ---> dmar_doma
Avi Kivity wrote:
> Han, Weidong wrote:
>>>
>>> There is a missed optimization here. Suppose we have two devices
>>> each under a different iommu. With the patch, each will be in a
>>> different dmar_domain and so will have a different page table. T
Han, Weidong wrote:
> Avi Kivity wrote:
>> Han, Weidong wrote:
>>>>
>>>> I don't want then to share dmar_domains (these are implementation
>>>> details anyway), just io page tables.
>>>>
>>>>
>>>> kv
Avi Kivity wrote:
> Han, Weidong wrote:
>> It's hard to move kvm_vtd_domain inside current iommu API. It's kvm
>> specific. It's not elegant to include kvm_vtd_domain stuffs in native
>> VT-d code.
>
> It's cleaner than adding knowledge of
Avi Kivity wrote:
> Han, Weidong wrote:
>>>
>>> 2.6.27 is out, so anything we do will be for 2.6.29.
>>>
>>
>> Do you mean the VT-d patches which haven't been checked in won't be
>> pushed into 2.6.28?
>>
>
> Yes. The on
Zwane Mwaikambo wrote:
> Hi,
> I've been trying to get a Linux guest working with PCI
passthrough
> of an ethernet card using the vtd branches. The device detection
> works and the guest reports a link, however as soon as i try and ping
> the guest it receives an NMI (i'm guessing this is PCI
Su, Disheng wrote:
> Amit Shah wrote:
>> This patch has been contributed to by the following people:
>>
>> From: Or Sagi <[EMAIL PROTECTED]>
>> From: Nir Peleg <[EMAIL PROTECTED]>
>> From: Amit Shah <[EMAIL PROTECTED]>
>> From: Ben-Ami Yassour <[EMAIL PROTECTED]>
>> From: Weidong Han <[EMAIL PROTE
[EMAIL PROTECTED] wrote:
> From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
>
> This patch has been contributed to by the following people:
>
> Or Sagi <[EMAIL PROTECTED]>
> Nir Peleg <[EMAIL PROTECTED]>
> Amit Shah <[EMAIL PROTECTED]>
> Ben-Ami Yassour <[EMAIL PROTECTED]>
> Weidong Han <[EMAIL PROTECTE
Han, Weidong wrote:
> [EMAIL PROTECTED] wrote:
>> From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
>>
>> This patch has been contributed to by the following people:
>>
>> Or Sagi <[EMAIL PROTECTED]>
>> Nir Peleg <[EMAIL PROTECTED]>
>> Ami
[EMAIL PROTECTED] wrote:
> From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
>
> This patch has been contributed to by the following people:
>
> Or Sagi <[EMAIL PROTECTED]>
> Nir Peleg <[EMAIL PROTECTED]>
> Amit Shah <[EMAIL PROTECTED]>
> Ben-Ami Yassour <[EMAIL PROTECTED]>
> Weidong Han <[EMAIL PROTECTE
Muli Ben-Yehuda wrote:
> On Tue, Oct 28, 2008 at 10:45:57AM -0500, Anthony Liguori wrote:
>
>>> +ifeq ($(USE_KVM), 1)
>>> +OBJS+= device-assignment.o
>>> +endif
>>
>> I don't think you want to build this on PPC so I think you need a
>> stronger check.
>
> Good point. How about checking TARGET_BA
Anthony Liguori wrote:
> [EMAIL PROTECTED] wrote:
>> This patchset enables device assignment for KVM hosts for PCI
>> devices. It uses the Intel IOMMU by default if available.
>>
>
> This is still broken wrt CPU hotplug. If a new CPU comes online, it
> won't have it's ioperm mask set correct and
>From 6eb40fddc2f09c3197c411f7ec56cf6034f833bd Mon Sep 17 00:00:00 2001
From: Weidong Han <[EMAIL PROTECTED]>
Date: Mon, 3 Nov 2008 17:09:06 +0800
Subject: [PATCH] Fix a bug in init_assigned_device
e_devfn is undefined. When DEVICE_ASSIGNMENT_DEBUG is on, compilation fails.
Signed-off-by: Weidong
>From fb7e8b1018ed8716a6fbdc30e519748567d24d55 Mon Sep 17 00:00:00 2001
From: Weidong Han <[EMAIL PROTECTED]>
Date: Thu, 6 Nov 2008 15:20:41 +0800
Subject: [PATCH] Fix command info expression of "pci_add"
Add a comma
Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
---
qemu/monitor.c |2 +-
1
Avi Kivity wrote:
> Han, Weidong wrote:
>> From 39ca008b144e1e729223b1302fcdd7a435370487 Mon Sep 17 00:00:00
>> 2001 From: Weidong Han <[EMAIL PROTECTED]>
>> Date: Mon, 10 Nov 2008 14:33:43 +0800
>> Subject: [PATCH] support ioperm for vcpu hotplug
>>
&g
>From 39ca008b144e1e729223b1302fcdd7a435370487 Mon Sep 17 00:00:00 2001
From: Weidong Han <[EMAIL PROTECTED]>
Date: Mon, 10 Nov 2008 14:33:43 +0800
Subject: [PATCH] support ioperm for vcpu hotplug
Track ioperm settings, when a new VCPU comes online, issue ioperm.
Signed-off-by: Weidong Han <[EMA
Guillaume Thouvenin wrote:
> On Tue, 11 Nov 2008 16:28:04 -
> Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>> @@ -450,6 +454,10 @@ static void *ap_main_loop(void *_env)
>> kvm_create_vcpu(kvm_context, env->cpu_index);
>> kvm_qemu_init_env(env);
>>
>> +/* do ioperm for io ports of
>From bba614bf2acf22f765995fb2364de04cec039226 Mon Sep 17 00:00:00 2001
From: Weidong Han <[EMAIL PROTECTED]>
Date: Fri, 14 Nov 2008 16:53:10 +0800
Subject: [PATCH] support VT-d device hotplug
wrap kvm_assign_device() and kvm_deassign_device() to support assign/deassign a
device to a guest
Signe
Currently, it doesn't handle cleanly for VT-d device hot add, because
kvm_map_guest() will allocate a dmar_domain. It should add a device to the
existed dmar_domain instead create a new one. For hot remove, it doesn't
release the device from adev_head list, remove its ioperm data from ioperm_hea
>From 79fd6880a8e7caaecc98e559a673400d20fb14be Mon Sep 17 00:00:00 2001
From: Weidong Han <[EMAIL PROTECTED]>
Date: Fri, 14 Nov 2008 16:31:12 +0800
Subject: [PATCH] Deassign ioctl
Add this to support hot remove assigned device
Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
---
libkvm/libkvm.c |
>From 9cf3b4c270c12f1ba966a033f3d207aed898a52a Mon Sep 17 00:00:00 2001
From: Weidong Han <[EMAIL PROTECTED]>
Date: Fri, 14 Nov 2008 16:35:16 +0800
Subject: [PATCH] Add interface to remove ioperm data
When hot remove assigned device, need to remove its ioperm data
Signed-off-by: Weidong Han <[EMA
>From 63d8eeeff86e881ab212baed4af51801dbb90460 Mon Sep 17 00:00:00 2001
From: Weidong Han <[EMAIL PROTECTED]>
Date: Fri, 14 Nov 2008 16:45:44 +0800
Subject: [PATCH] support hot remove assigned device
When hot remove assigned device, deassign it from guest, delete it from
adev_head and remove its
Avi Kivity wrote:
> Han, Weidong wrote:
>> From bba614bf2acf22f765995fb2364de04cec039226 Mon Sep 17 00:00:00
>> 2001
>> From: Weidong Han <[EMAIL PROTECTED]>
>> Date: Fri, 14 Nov 2008 16:53:10 +0800
>> Subject: [PATCH] support VT-d device hotp
Avi Kivity wrote:
> Han, Weidong wrote:
>>> Need a KVM_CAP_ to indicate this is available.
>>>
>>>
>>
>> KVM_ASSIGN_PCI_DEVICE and KVM_ASSIGN_IRQ don't need a KVM_CAP_xxx.
>> Why do you need it for KVM_DEASSIGN_PCI_DEVICE?
>>
>&g
Avi Kivity wrote:
> Han, Weidong wrote:
>> Avi Kivity wrote:
>>
>>> Han, Weidong wrote:
>>>
>>>>> Need a KVM_CAP_ to indicate this is available.
>>>>>
>>>>>
>>>>>
>>>> KVM_ASSIGN_PC
Avi Kivity wrote:
> Han, Weidong wrote:
>>> This is how KVM_CAP_ works:
>>>
>>> - kvm.h defines KVM_CAP_DEVICE_ASSIGNMENT
>>> - userspace compiles device assignment code only if it sees
>>> KVM_CAP_DEVICE_ASSIGNMENT in kvm.h
>>&
In native VT-d usage, one domain (dmar_domain) owns one device (PCI-e). KVM
uses VT-d driver to assign device, so currently kvm VT-d only supports assign
single device to a guest.
While in KVM VT-d usage, multiple devices from different iommus can be assigned
to one guest. In order to support
This patch changes to use new APIs for KVM VT-d, and add device deassignment
for hotplug.
Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
---
include/linux/kvm.h |2 +
include/linux/kvm_host.h | 23 --
virt/kvm/kvm_main.c | 45 ++-
virt/kvm/vtd.c
Avi Kivity wrote:
> Han, Weidong wrote:
>> In order to support multiple device assignment for KVM, this patch
>> does following main changes:
>>- extend dmar_domain to own multiple devices from different
>> iommus, use a bitmap of iommus to replace iomm
Avi Kivity wrote:
> Han, Weidong wrote:
>> This patch changes to use new APIs for KVM VT-d, and add device
>> deassignment for hotplug.
>>
>> index 44fd7fa..558bc32 100644
>> --- a/include/linux/kvm.h
>> +++ b/include/linux/kvm.h
>
Yu, Fenghua wrote:
> Avi Kivity wrote:
>>> Han, Weidong wrote:
>>>> In order to support multiple device assignment for KVM, this patch
>>>>does following main changes: - extend dmar_domain to own
>>>> multiple devices from different iommus,
When user wants to assign device with IOMMU, but IOMMU is not
enabled, add warning messages to prompt user this situation, and
return error. Or device will be assigned but it cannot work.
Signed-off-by: Weidong Han
---
qemu/hw/device-assignment.c |5 +
1 files changed, 5 insertions(+), 0
Device assignment command is like "-pcidevice host=xx:yy.z".
Check bus:dev.func length to make sure its format is xx:yy.z.
Signed-off-by: Weidong Han
---
qemu/hw/device-assignment.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/qemu/hw/device-assignment.c b/qemu/hw
Avi Kivity wrote:
> Han, Weidong wrote:
>> When user wants to assign device with IOMMU, but IOMMU is not
>> enabled, add warning messages to prompt user this situation, and
>> return error. Or device will be assigned but it cannot work.
>>
>
> If the device has d
Avi Kivity wrote:
> Han, Weidong wrote:
>> Device assignment command is like "-pcidevice host=xx:yy.z".
>> Check bus:dev.func length to make sure its format is xx:yy.z.
>>
>> Signed-off-by: Weidong Han
>> ---
>> qemu/hw/device-assignment.c |
Avi Kivity wrote:
> Han, Weidong wrote:
>>> I suggest replacing the parsing code with pci_parse_devaddr() (needs
>>> to be extended to support functions) so that all the checking and
>>> parsing is done in one place.
>>>
>>
>> If use pci
Hi,
Currently, expansion ROM of assigned devices will be loaded into guest and
execute. You can just comment out one line code (assigned_dev_load_option_rom()
in qemu/hw/pc.c) to let qemu don't load expansion ROM, and then this issue
should be gone. I met this issue before, but there was no pro
hotplug is supported. You can refer to
http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM.
Regards,
Weidong
Aaron Dailey wrote:
> I'm interested in using PCI passthrough on a PCI device that may not
> be present at boot time, but is later inserted. Is this possible in
> KVM? I
Yuji virtualized more capabilities to guest in Xen Qemu. I think your tg3
driver can work in Xen guest with VT-d passthrough. If anyone interests, he/she
can port the code from Xen Qemu to KVM Qemu.
Regards,
Weidong
Alex Williamson wrote:
> On Wed, May 6, 2009 at 11:31 AM, Nadolski, Ed
> wrote
Siddha, Suresh B wrote:
> On Wed, 2009-05-06 at 23:16 -0700, Han, Weidong wrote:
>> @@ -634,6 +694,44 @@ static int ir_parse_ioapic_scope(struct
>> acpi_dmar_header *header, " 0x%Lx\n",
>> scope
Ingo Molnar wrote:
> * Han, Weidong wrote:
>
>> Siddha, Suresh B wrote:
>>> On Wed, 2009-05-06 at 23:16 -0700, Han, Weidong wrote:
>>>> @@ -634,6 +694,44 @@ static int ir_parse_ioapic_scope(struct
>>>>
Ingo Molnar wrote:
> * Han, Weidong wrote:
>
>> Ingo Molnar wrote:
>>> * Han, Weidong wrote:
>>>
>>>> Siddha, Suresh B wrote:
>>>>> On Wed, 2009-05-06 at 23:16 -0700, Han, Weidong wrote:
>>&g
Ingo Molnar wrote:
> * Weidong Han wrote:
>
>> To support domain-isolation usages, the platform hardware must be
>> capable of uniquely identifying the requestor (source-id) for each
>> interrupt message. Without source-id checking for interrupt
>> remapping , a rouge guest/VM with assigned devic
Ingo Molnar wrote:
> * Weidong Han wrote:
>
>> Interrupt remapping table entry is 128bits. Currently, it only sets
>> low 64bits of irte in modify_irte and free_irte. This ignores high
>> 64bits setting of irte, that means source-id setting will be
>> ignored. This patch sets the whole 128bits of
Ingo Molnar wrote:
> * Eric W. Biederman wrote:
>
>> Ingo Molnar writes:
>>
>>> * Weidong Han wrote:
>>>
To support domain-isolation usages, the platform hardware must be
capable of uniquely identifying the requestor (source-id) for each
interrupt message. Without source-id che
Ingo Molnar wrote:
> * Eric W. Biederman wrote:
>
>> Not finding an upstream pcie_bridge and then concluding we are a
>> pcie device seems bogus.
>>
If device is pcie, pci_find_upstream_pcie_bridge() will return NULL. For root
complex integrated device, it won't find upstream bridge, and also
1 - 100 of 262 matches
Mail list logo
