On 2017年10月26日 22:27, Michael S. Tsirkin wrote:
> On Thu, Oct 26, 2017 at 02:19:43PM +0200, Eduardo Habkost wrote:
>> On Mon, Aug 21, 2017 at 10:22:15AM +0800, Lan Tianyu wrote:
>>> On 2017年08月19日 00:38, Eduardo Habkost wrote:
>>>> On Thu, Aug 17, 2017 at 09:3
On 2017年08月19日 00:38, Eduardo Habkost wrote:
> On Thu, Aug 17, 2017 at 09:37:10AM +0800, Lan Tianyu wrote:
>> On 2017年08月16日 19:21, Paolo Bonzini wrote:
>>> On 16/08/2017 02:22, Lan Tianyu wrote:
>>>> Xen vIOMMU device model will be in Xen hypervisor. Skip vIOMMU
>
On 2017年08月16日 19:21, Paolo Bonzini wrote:
> On 16/08/2017 02:22, Lan Tianyu wrote:
>> Xen vIOMMU device model will be in Xen hypervisor. Skip vIOMMU
>> check for Xen here when vcpu number is more than 255.
>
> I think you still need to do a check for vIOMMU being enabled.
Y
Xen vIOMMU device model will be in Xen hypervisor. Skip vIOMMU
check for Xen here when vcpu number is more than 255.
Signed-off-by: Lan Tianyu
---
hw/i386/pc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 5943539..fc17885 100644
--- a/hw
For HPC usage case, it will create a huge VM with vcpus number as same as host
cpus and this requires more vcpus support in a single VM. This patch is to
increase max vcpu number from 288 to 8192 which is current default maximum cpu
number for Linux kernel.
Signed-off-by: Lan Tianyu
---
hw/i386
Signed-off-by: Lan Tianyu
---
hw/i386/pc_piix.c| 14 +++---
hw/i386/pc_q35.c | 14 +++---
include/hw/compat.h | 3 +++
include/hw/i386/pc.h | 3 +++
4 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 11b4336
Hi Anthony:
On 2017年08月12日 02:04, Anthony PERARD wrote:
> On Wed, Aug 09, 2017 at 04:51:21PM -0400, Lan Tianyu wrote:
>> From: Chao Gao
>>
>> If a vIOMMU is exposed to guest, guest will configure the msi to remapping
>> format. The original code isn't suitab
Intel Xeon phi chip will support 352 logical threads. For HPC
usage case, it will create a huge VM with vcpus number as same as host
cpus. This patch is to increase max vcpu number from 288 to 8192 which
is current default maximum cpu number for Linux kernel.
Signed-off-by: Lan Tianyu
---
Change
Intel Xeon phi chip will support 352 logical threads. For HPC
usage case, it will create a huge VM with vcpus number as same as host
cpus. This patch is to increase max vcpu number from 288 to 8192 which
is current default maximum cpu number for Linux kernel.
Signed-off-by: Lan Tianyu
---
Change
On 2017年08月11日 03:22, Radim Krčmář wrote:
> 2017-08-10 15:16-0300, Eduardo Habkost:
>> On Thu, Aug 10, 2017 at 02:41:03PM +0200, Radim Krčmář wrote:
>>> 2017-08-10 19:02+0800, Lan Tianyu:
>>>> On 2017年08月10日 18:26, Daniel P. Berrange wrote:
>>>>>
On 2017年08月10日 18:26, Daniel P. Berrange wrote:
> On Thu, Aug 10, 2017 at 06:08:07PM +0800, Lan Tianyu wrote:
>> Intel Xeon phi chip will support 352 logical threads. For HPC
>> usage case, it will create a huge VM with vcpus number as same as host
>> cpus. This patch is
Intel Xeon phi chip will support 352 logical threads. For HPC
usage case, it will create a huge VM with vcpus number as same as host
cpus. This patch is to increase max vcpu number to 352.
Signed-off-by: Lan Tianyu
---
hw/i386/pc_q35.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Intel Xeon phi chip will support 352 logical threads. For HPC
usage case, it will create a huge VM with vcpus number as same as host
cpus. This patch is to increase max vcpu number to 352.
Signed-off-by: Lan Tianyu
---
hw/i386/pc_q35.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On 2017年08月10日 17:04, Paolo Bonzini wrote:
> On 09/08/2017 22:51, Lan Tianyu wrote:
>> This patchset is to deal with MSI interrupt remapping request when guest
>> updates MSI registers.
>>
>> Chao Gao (3):
>> i386/msi: Correct mask of destination ID in MSI
igned-off-by: Chao Gao
Signed-off-by: Lan Tianyu
---
configure | 4 +++-
hw/xen/xen_pt_msi.c | 50 ---
include/hw/i386/apic-msidef.h | 1 +
include/hw/xen/xen_common.h | 25 ++
4 files changed, 66 inser
binded with an event channel.
Signed-off-by: Chao Gao
Signed-off-by: Lan Tianyu
Acked-by: Anthony PERARD
---
hw/i386/xen/xen-hvm.c | 8 +++-
hw/pci/msi.c | 5 +++--
hw/pci/msix.c | 4 +++-
hw/xen/xen_pt_msi.c | 2 +-
include/hw/xen/xen.h | 2 +-
stubs/xen-hvm.c | 2
This patchset is to deal with MSI interrupt remapping request when guest
updates MSI registers.
Chao Gao (3):
i386/msi: Correct mask of destination ID in MSI address
xen-pt: bind/unbind interrupt remapping format MSI
msi: Handle remappable format interrupt request
configure
From: Chao Gao
According to SDM 10.11.1, only [19:12] bits of MSI address are
Destination ID, change the mask to avoid ambiguity for VT-d spec
has used the bit 4 to indicate a remappable interrupt request.
Signed-off-by: Chao Gao
Signed-off-by: Lan Tianyu
Reviewed-by: Anthony PERARD
Reviewed
Hi Anthony:
On 2017年06月30日 23:48, Anthony PERARD wrote:
> On Thu, Jun 29, 2017 at 01:49:53AM -0400, Lan Tianyu wrote:
>> From: Chao Gao
>>
>> If a vIOMMU is exposed to guest, guest will configure the msi to remapping
>> format. The original code isn't suitab
From: Chao Gao
According to SDM 10.11.1, only [19:12] bits of MSI address are
Destination ID, change the mask to avoid ambiguity for VT-d spec
has used the bit 4 to indicate a remappable interrupt request.
Signed-off-by: Chao Gao
Signed-off-by: Lan Tianyu
---
include/hw/i386/apic-msidef.h
binded with an event channel.
Signed-off-by: Chao Gao
Signed-off-by: Lan Tianyu
---
hw/pci/msi.c | 5 +++--
hw/pci/msix.c| 4 +++-
hw/xen/xen_pt_msi.c | 2 +-
include/hw/xen/xen.h | 2 +-
xen-hvm-stub.c | 2 +-
xen-hvm.c| 8 +++-
6 files changed, 16 insertions
igned-off-by: Chao Gao
Signed-off-by: Lan Tianyu
---
configure | 54 +++
hw/xen/xen_pt_msi.c | 50 ---
include/hw/i386/apic-msidef.h | 1 +
include/hw/xen/xen_common.h | 25 ++
This patchset is to deal with MSI interrupt remapping request when guest
updates MSI registers.
Chao Gao (3):
i386/msi: Correct mask of destination ID in MSI address
xen-pt: bind/unbind interrupt remapping format MSI
msi: Handle remappable format interrupt request
configure
On 2017年05月24日 01:06, Anthony PERARD wrote:
> On Tue, May 23, 2017 at 08:16:25PM +0800, Lan Tianyu wrote:
>> On 2017年05月19日 20:04, Jan Beulich wrote:
>>>>>> On 19.05.17 at 13:16, wrote:
>>>> On Thu, May 18, 2017 at 01:32:59AM -0400, Lan Tianyu wrote:
&g
On 2017年05月19日 20:04, Jan Beulich wrote:
>>>> On 19.05.17 at 13:16, wrote:
>> On Thu, May 18, 2017 at 01:32:59AM -0400, Lan Tianyu wrote:
>>> --- a/include/hw/i386/apic-msidef.h
>>> +++ b/include/hw/i386/apic-msidef.h
>>> @@ -26,6 +26,7 @@
>>
Hi Anthony:
Thanks for your review.
On 2017年05月19日 19:57, Anthony PERARD wrote:
> On Thu, May 18, 2017 at 01:33:00AM -0400, Lan Tianyu wrote:
>> From: Chao Gao
>>
>> According to VT-d spec Interrupt Remapping and Interrupt Posting ->
>> Interrupt Remapping -
d-off-by: Chao Gao
Signed-off-by: Lan Tianyu
---
hw/xen/xen_pt_msi.c | 50 ---
include/hw/i386/apic-msidef.h | 3 ++-
2 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 62add06..5f
Change since V1:
1) Move create/destroy vIOMMU and query vIOMMU capabilities to tool
stack.
2) Fix some code style issue.
This patchset is to deal with MSI interrupt remapping request when guest
updates MSI registers.
Repo:
https://github.com/lantianyu/qemu/tree/xen_viommu_rfc_v2
binded with an event channel.
Signed-off-by: Chao Gao
Signed-off-by: Lan Tianyu
---
hw/pci/msi.c | 5 +++--
hw/pci/msix.c| 4 +++-
hw/xen/xen_pt_msi.c | 2 +-
include/hw/xen/xen.h | 2 +-
xen-hvm-stub.c | 2 +-
xen-hvm.c| 7 ++-
6 files changed, 15 insertions
On 2017年04月26日 18:06, Liu, Yi L wrote:
> Add FOR_EACH_ASSIGN_DEVICE. It would be used to loop all assigned
> devices when processing guest pasid table linking and iommu cache
> invalidate propagation.
>
> Signed-off-by: Liu, Yi L
> ---
> hw/i386/intel_iommu.c | 32 ++
On 2017年04月26日 18:06, Liu, Yi L wrote:
> With vIOMMU exposed to guest, vIOMMU emulator needs to do translation
> between host and guest. e.g. a device-selective TLB flush, vIOMMU
> emulator needs to replace guest SID with host SID so that to limit
> the invalidation. This patch introduces a new cal
On 2017年04月27日 18:32, Peter Xu wrote:
> On Wed, Apr 26, 2017 at 06:06:32PM +0800, Liu, Yi L wrote:
>> VT-d implementations reporting PASID or PRS fields as "Set", must also
>> report ecap.ECS as "Set". Extended-Context is required for SVM.
>>
>> When ECS is reported, intel iommu driver would initia
On 2017年04月20日 15:04, Peter Xu wrote:
> On Thu, Apr 20, 2017 at 06:36:16AM +, Liu, Yi L wrote:
>
> [...]
>
In my understanding, container->space->as->root cannot work here no
matter passthru-mode is enabled or not. The code here is aiming to
check if vIOMMU exists. After the vf
On 4/20/2017 1:40 PM, Peter Xu wrote:
On Thu, Apr 20, 2017 at 04:55:24AM +, Liu, Yi L wrote:
[...]
In my previous RFC patchset of fault event reporting, I registered
fault notifier when there is a VFIO group attached to VFIO container
and used the address space to check whether vIOMMU is a
Hi All:
Sorry for later response.
On 2017年04月18日 17:04, Liu, Yi L wrote:
>> -Original Message-
>> From: Peter Xu [mailto:pet...@redhat.com]
>> Sent: Tuesday, April 18, 2017 3:27 PM
>> To: Liu, Yi L
>> Cc: qemu-devel@nongnu.org; Lan, Tianyu ; Micha
On 2017年03月20日 19:38, Paolo Bonzini wrote:
> Fair enough, though I'd be worried about increasing the attack surface
> of the hypervisor. For KVM, for example, IOMMU emulation requires using
> the "split irqchip" feature to move the PIC and IOAPIC out of the kernel
> and back to QEMU.
Yes, just li
Hi Eduardo:
Thanks for your review.
On 2017年03月21日 03:49, Eduardo Habkost wrote:
> On Fri, Mar 17, 2017 at 07:29:14PM +0800, Lan Tianyu wrote:
>> From: Chao Gao
>>
>> xen-viommu will be a sysbus device and the device model will
>> be enabled via "-device
On 2017年03月17日 22:48, Paolo Bonzini wrote:
>
>
> On 17/03/2017 12:29, Lan Tianyu wrote:
>> This patchset is to add Xen vIOMMU device model and handle
>> irq remapping stuffs. Xen vIOMMU emulation is in the Xen hypervisor
>> and the new device module in Qemu wor
e msi interrupt format into consideration.
Signed-off-by: Chao Gao
Signed-off-by: Lan Tianyu
---
hw/pci/msi.c | 5 +++--
hw/pci/msix.c| 4 +++-
hw/xen/xen_pt_msi.c | 2 +-
include/hw/xen/xen.h | 2 +-
xen-hvm-stub.c | 2 +-
xen-hvm.c| 7 ++-
6 files change
From: Chao Gao
Since adding a dynamic sysbus device is forbidden, so choose TYPE_DEVICE
as parent class.
Signed-off-by: Chao Gao
Signed-off-by: Lan Tianyu
---
hw/xen/Makefile.objs | 1 +
hw/xen/xen_viommu.c | 116 +++
2 files changed, 117
d-off-by: Chao Gao
Signed-off-by: Lan Tianyu
---
hw/xen/xen_pt_msi.c | 36
include/hw/i386/apic-msidef.h | 1 +
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 62add06..8b0d7fc 100644
From: Chao Gao
xen-viommu will be a sysbus device and the device model will
be enabled via "-device" parameter.
Signed-off-by: Chao Gao
Signed-off-by: Lan Tianyu
---
hw/i386/pc_piix.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
ind
This patchset is to add Xen vIOMMU device model and handle
irq remapping stuffs. Xen vIOMMU emulation is in the Xen hypervisor
and the new device module in Qemu works as hypercall wrappers to
create and destroy vIOMMU in hypervisor.
Xen only supports emulated I440 and so we enable vIOMMU with emul
This patch is to deal with fault event reported from IOMMU driver.
Signed-off-by: Lan Tianyu
---
hw/i386/intel_iommu.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 9b1ba1b..79507d2 100644
--- a/hw/i386
confirm
interface between Qemu and VFIO kernel driver is on the right way.
Very appreciate for comments.
Lan Tianyu (4):
VFIO: Set eventfd for IOMMU fault event via new vfio cmd
Memory: Introduce IOMMU fault event callback
Intel iommu: Add Intel IOMMU fault event callback
VFIO: Read IOMMU
This patch is to implement fault event handler with new vfio cmd to
get fault info and notify vIOMMU device model.
Signed-off-by: Lan Tianyu
---
hw/vfio/common.c | 51 ++
linux-headers/linux/vfio.h | 22
2 files changed
This patch is to assign an event fd to VFIO IOMMU type1 driver
in order to get notification when IOMMU driver reports fault event.
Signed-off-by: Lan Tianyu
---
hw/vfio/common.c | 37 +
include/hw/vfio/vfio-common.h | 3 +++
linux-headers/linux
On 2016年12月08日 10:39, Peter Xu wrote:
> Btw, do you have time to help review my RFC series for "vt-d replay"?
> :) I'd like to receive any further review comments besides the issues
> mentioned above since IMHO they can be seperated from current series,
> I have noted them down in my pending list.
On 2016年12月06日 18:36, Peter Xu wrote:
> +/**
> + * vtd_page_walk - walk specific IOVA range, and call the hook
> + *
> + * @ce: context entry to walk upon
> + * @start: IOVA address to start the walk
> + * @end: size of the IOVA range to walk over
*·@end:·IOVA·range·end·address·(start·<=·addr·<·e
On 2016年12月07日 14:43, Peter Xu wrote:
On Wed, Dec 07, 2016 at 02:09:16PM +0800, Lan Tianyu wrote:
On 2016年12月06日 18:59, Peter Xu wrote:
On Tue, Dec 06, 2016 at 04:27:39PM +0800, Lan Tianyu wrote:
[...]
User space driver(E.G DPDK) also can enable/disable
IOVA for device dynamically
On 2016年12月06日 18:59, Peter Xu wrote:
> On Tue, Dec 06, 2016 at 04:27:39PM +0800, Lan Tianyu wrote:
>
> [...]
>
>>>
>>>> User space driver(E.G DPDK) also can enable/disable
>>>> IOVA for device dynamically.
>>>
>>> Could you provide
On 2016年12月06日 15:22, Peter Xu wrote:
> On Tue, Dec 06, 2016 at 03:06:20PM +0800, Lan Tianyu wrote:
>> On 2016年12月06日 14:51, Peter Xu wrote:
>>> On Tue, Dec 06, 2016 at 02:30:24PM +0800, Lan Tianyu wrote:
>>>
>>> [...]
>>>
>>>>>> 2.
On 2016年12月06日 14:51, Peter Xu wrote:
> On Tue, Dec 06, 2016 at 02:30:24PM +0800, Lan Tianyu wrote:
>
> [...]
>
>>>> 2. How to restore GPA->HPA mapping when IOVA is disabled by guest.
>>>> When guest enables IOVA for device, vIOMMU will invalidate all pr
On 2016年12月02日 14:52, Peter Xu wrote:
> On Thu, Dec 01, 2016 at 02:44:14PM +0800, Lan Tianyu wrote:
>
> [...]
>
>> Hi:
>> I think there are still other gaps to enable passthough device with
>> vIOMMU's DMA translation support.
>>
>> 1. Since th
On 12/3/2016 1:30 AM, Alex Williamson wrote:
> On Fri, 2 Dec 2016 14:08:59 +0800
> Peter Xu wrote:
>
>> On Thu, Dec 01, 2016 at 04:27:52PM +0800, Lan Tianyu wrote:
>>> On 2016年11月30日 17:23, Peter Xu wrote:
>>>> On Mon, Nov 28, 2016 at 05:51:50PM +0200, Aviv B.D
On 2016年11月30日 17:23, Peter Xu wrote:
> On Mon, Nov 28, 2016 at 05:51:50PM +0200, Aviv B.D wrote:
>> * intel_iommu's replay op is not implemented yet (May come in different
>> patch
>> set).
>> The replay function is required for hotplug vfio device and to move
>> devices
>> between exist
On 2016年12月01日 12:21, Tian, Kevin wrote:
>> I am thinking about this replay thing recently and now I start to
>> > doubt whether the whole vt-d vIOMMU framework suites this...
>> >
>> > Generally speaking, current work is throwing away the IOMMU "domain"
>> > layer here. We maintain the mapping on
On 2016年11月28日 23:51, Aviv B.D wrote:
> From: "Aviv Ben-David"
>
> * Advertize Cache Mode capability in iommu cap register.
> This capability is controlled by "cache-mode" property of intel-iommu
> device.
> To enable this option call QEMU with "-device intel-iommu,cache-mode=true".
>
> * On
On 2016年09月23日 13:26, Peter Xu wrote:
> On Thu, Sep 22, 2016 at 12:34:36PM +0800, Chao Gao wrote:
>> Hi, we had 3 problems left here.
>> 1. IRQremapping can't work with x2apic_cluster mode.
>> 2. apic_id > 255 can't receive devices interrupts.
>> 3. windows crash when present IRQremapping capabilit
On 3/1/2016 10:00 PM, Eduardo Habkost wrote:
On Mon, Feb 29, 2016 at 10:56:04AM +0800, Lan Tianyu wrote:
On 2016年02月27日 03:54, Eduardo Habkost wrote:
On Thu, Feb 25, 2016 at 11:15:12PM +0800, Lan Tianyu wrote:
x2apic feature is in the kvm_default_props and automatically added to all
CPU
On 2016年02月27日 03:54, Eduardo Habkost wrote:
> On Thu, Feb 25, 2016 at 11:15:12PM +0800, Lan Tianyu wrote:
>> x2apic feature is in the kvm_default_props and automatically added to all
>> CPU models when KVM is enabled. But userspace devices don't support x2apic
>> whic
.01H:ECX.x2apic
[bit 21]" when kernel_irqchip is off. This patch is to fix it via removing
x2apic feature when kernel_irqchip is off.
Signed-off-by: Lan Tianyu
---
target-i386/cpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index c78f824..29
2016-02-25 16:39 GMT+08:00 Jan Kiszka :
> On 2016-02-25 09:33, Lan Tianyu wrote:
>> 2016-02-20 17:00 GMT+08:00 Paolo Bonzini :
>>>
>>>
>>> - Original Message -
>>>> From: "Jan Kiszka"
>>>> To: "Eduardo Habkost&q
The patch is to fix the issue.
->8
>From 58f2a3a94c8e7bf9f3474bcafb6c59cc4f8bcbd9 Mon Sep 17 00:00:00 2001
From: Lan Tianyu
Date: Sun, 15 Jul 2001 01:40:17 -0400
Subject: [PATCH] Qemu/KVM: Remove x2apic feature from CPU model when
On 2015年12月30日 00:46, Michael S. Tsirkin wrote:
> Interesting. So you sare saying merely ifdown/ifup is 100ms?
> This does not sound reasonable.
> Is there a chance you are e.g. getting IP from dhcp?
>
> If so that is wrong - clearly should reconfigure the old IP
> back without playing with dhcp.
On 12/25/2015 8:11 PM, Michael S. Tsirkin wrote:
As long as you keep up this vague talk about performance during
migration, without even bothering with any measurements, this patchset
will keep going nowhere.
I measured network service downtime for "keep device alive"(RFC patch V1
presented
Merry Christmas.
Sorry for later response due to personal affair.
On 2015年12月14日 03:30, Alexander Duyck wrote:
>> > These sounds we need to add a faked bridge for migration and adding a
>> > driver in the guest for it. It also needs to extend PCI bus/hotplug
>> > driver to do pause/resume other de
On 12/11/2015 1:16 AM, Alexander Duyck wrote:
On Thu, Dec 10, 2015 at 6:38 AM, Lan, Tianyu wrote:
On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
Ideally, it is able to leave guest driver unmodified but it requires the
hypervisor or qemu to aware the device which means we may need
On 12/11/2015 12:11 AM, Michael S. Tsirkin wrote:
On Thu, Dec 10, 2015 at 10:38:32PM +0800, Lan, Tianyu wrote:
On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
Ideally, it is able to leave guest driver unmodified but it requires the
hypervisor or qemu to aware the device which means
On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
Ideally, it is able to leave guest driver unmodified but it requires the
>hypervisor or qemu to aware the device which means we may need a driver in
>hypervisor or qemu to handle the device on behalf of guest driver.
Can you answer the quest
On 12/10/2015 4:38 PM, Michael S. Tsirkin wrote:
Let's assume you do save state and do have a way to detect
whether state matches a given hardware. For example,
driver could store firmware and hardware versions
in the state, and then on destination, retrieve them
and compare. It will be pretty co
On 12/10/2015 1:14 AM, Alexander Duyck wrote:
On Wed, Dec 9, 2015 at 8:26 AM, Lan, Tianyu wrote:
For other kind of devices, it's hard to work.
We are also adding migration support for QAT(QuickAssist Technology) device.
QAT device user case introduction.
Server, networking, big data
On 12/10/2015 4:07 AM, Michael S. Tsirkin wrote:
On Thu, Dec 10, 2015 at 12:26:25AM +0800, Lan, Tianyu wrote:
On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote:
I thought about what this is doing at the high level, and I do have some
value in what you are trying to do, but I also think we need
On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote:
I thought about what this is doing at the high level, and I do have some
value in what you are trying to do, but I also think we need to clarify
the motivation a bit more. What you are saying is not really what the
patches are doing.
And with tha
On 12/9/2015 7:28 PM, Michael S. Tsirkin wrote:
I remember reading that it's possible to implement a bus driver
on windows if required. But basically I don't see how windows can be
relevant to discussing guest driver patches. That discussion
probably belongs on the qemu maling list, not on lkml.
On 12/9/2015 6:37 PM, Michael S. Tsirkin wrote:
On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote:
Hi Michael & Alexander:
Thanks a lot for your comments and suggestions.
It's nice that it's appreciated, but you then go on and ignore
all that I have written here:
ht
On 12/8/2015 1:12 AM, Alexander Duyck wrote:
On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
On 12/5/2015 1:07 AM, Alexander Duyck wrote:
We still need to support Windows guest for migration and this is why our
patches keep all changes in the driver since it's impossible to c
On 12/5/2015 1:07 AM, Alexander Duyck wrote:
We still need to support Windows guest for migration and this is why our
patches keep all changes in the driver since it's impossible to change
Windows kernel.
That is a poor argument. I highly doubt Microsoft is interested in
having to modify all
Hi Michael & Alexander:
Thanks a lot for your comments and suggestions.
We still need to support Windows guest for migration and this is why our
patches keep all changes in the driver since it's impossible to change
Windows kernel.
Following is my idea to do DMA tracking.
Inject event to VF
On 12/4/2015 4:05 PM, Michael S. Tsirkin wrote:
I haven't read it, but I would like to note you can't rely on research
papers. If you propose a patch to be merged you need to measure what is
its actual effect on modern linux at the end of 2015.
Sure. Will do that.
On 12/2/2015 10:31 PM, Michael S. Tsirkin wrote:
>We hope
>to find a better way to make SRIOV NIC work in these cases and this is
>worth to do since SRIOV NIC provides better network performance compared
>with PV NIC.
If this is a performance optimization as the above implies,
you need to inclu
On 12/2/2015 10:31 PM, Michael S. Tsirkin wrote:
>We hope
>to find a better way to make SRIOV NIC work in these cases and this is
>worth to do since SRIOV NIC provides better network performance compared
>with PV NIC.
If this is a performance optimization as the above implies,
you need to inclu
On 12/3/2015 6:25 AM, Alex Williamson wrote:
This will of course break if the PCI SIG defines that capability index.
Couldn't this be done within a vendor defined capability? Thanks,
Yes, it should work and thanks for suggestion.
On 12/3/2015 6:25 AM, Alex Williamson wrote:
On Tue, 2015-11-24 at 21:35 +0800, Lan Tianyu wrote:
This patch is to add SRIOV VF migration support.
Create new device type "vfio-sriov" and add faked PCI migration capability
to the type device.
The purpose of the new capabili
On 12/3/2015 6:25 AM, Alex Williamson wrote:
I didn't seen a matching kernel patch series for this, but why is the
kernel more capable of doing this than userspace is already?
The following link is the kernel patch.
http://marc.info/?l=kvm&m=144837328920989&w=2
These seem
like pointless ioctl
On 12/1/2015 11:02 PM, Michael S. Tsirkin wrote:
But
it requires guest OS to do specific configurations inside and rely on
bonding driver which blocks it work on Windows.
From performance side,
putting VF and virtio NIC under bonded interface will affect their
performance even when not do migrat
On 12/1/2015 12:07 AM, Alexander Duyck wrote:
They can only be corrected if the underlying assumptions are correct
and they aren't. Your solution would have never worked correctly.
The problem is you assume you can keep the device running when you are
migrating and you simply cannot. At some
On 11/30/2015 4:01 PM, Michael S. Tsirkin wrote:
It is still not very clear what it is you are trying to achieve, and
whether your patchset achieves it. You merely say "adding live
migration" but it seems pretty clear this isn't about being able to
migrate a guest transparently, since you are
On 11/26/2015 11:56 AM, Alexander Duyck wrote:
> I am not saying you cannot modify the drivers, however what you are
doing is far too invasive. Do you seriously plan on modifying all of
the PCI device drivers out there in order to allow any device that
might be direct assigned to a port to suppo
On 11/25/2015 8:28 PM, Michael S. Tsirkin wrote:
Frankly, I don't really see what this short term hack buys us,
and if it goes in, we'll have to maintain it forever.
The framework of how to notify VF about migration status won't be
changed regardless of stopping VF or not before doing migratio
On 11/25/2015 5:03 AM, Michael S. Tsirkin wrote:
>+void vfio_migration_cap_handle(PCIDevice *pdev, uint32_t addr,
>+ uint32_t val, int len)
>+{
>+VFIOPCIDevice *vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev);
>+
>+if (addr == vdev->migration_cap + PCI_VF_MIG
On 2015年11月25日 13:30, Alexander Duyck wrote:
> No, what I am getting at is that you can't go around and modify the
> configuration space for every possible device out there. This
> solution won't scale.
PCI config space regs are emulation by Qemu and so We can find the free
PCI config space regs
On 2015年11月25日 05:20, Michael S. Tsirkin wrote:
> I have to say, I was much more interested in the idea
> of tracking dirty memory. I have some thoughts about
> that one - did you give up on it then?
No, our finial target is to keep VF active before doing
migration and tracking dirty memory is ess
On 2015年11月24日 22:20, Alexander Duyck wrote:
> I'm still not a fan of this approach. I really feel like this is
> something that should be resolved by extending the existing PCI hot-plug
> rather than trying to instrument this per driver. Then you will get the
> goodness for multiple drivers and
Signed-off-by: Lan Tianyu
---
hw/vfio/pci.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index e7583b5..404a5cd 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -3625,11 +3625,6 @@ static Property vfio_pci_dev_properties
This patch is to add a callback which is called just before stopping VCPU.
It's for VF migration to trigger mailbox irq as later as possible to
decrease service downtime.
Signed-off-by: Lan Tianyu
---
include/migration/vmstate.h | 3 +++
include/sysemu/sysemu.h | 1 +
migr
TUS in the new cap table
to tell Qemu.
Signed-off-by: Lan Tianyu
---
hw/vfio/Makefile.objs | 2 +-
hw/vfio/pci.c | 6 ++
hw/vfio/pci.h | 4 ++
hw/vfio/sriov.c | 178 ++
4 files changed, 189 insertions(+), 1 deletion(-)
c
), mailbox irq won't be
triggered and VF driver will disable it via PCI_VF_MIGRATION_CAP
reg. These case will be resolved later.
Signed-off-by: Lan Tianyu
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 5 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 102
: Lan Tianyu
---
include/migration/vmstate.h | 2 ++
migration/savevm.c | 15 +++
2 files changed, 17 insertions(+)
diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
index 0695d7c..dc681a6 100644
--- a/include/migration/vmstate.h
+++ b/include/migration
This patch is to add new ioctl cmd VFIO_GET_PCI_CAP_INFO to get
PCI cap table size and get free PCI config space regs according
pos and size.
Qemu will add faked PCI capability for migration and need such
info.
Signed-off-by: Lan Tianyu
---
drivers/vfio/pci/vfio_pci.c | 21
1 - 100 of 141 matches
Mail list logo
