On Tue, Apr 11, 2017 at 02:21:07AM -0600, Jan Beulich wrote:
On 11.04.17 at 02:59, wrote:
>> As you know, with VT-d PI enabled, hardware can directly deliver external
>> interrupts to guest without any VMM intervention. It will reduces overall
>> interrupt latency to guest and reduces overhea
On Fri, Apr 14, 2017 at 04:34:41PM +0100, Roger Pau Monné wrote:
>Hello,
>
>Although PVHv2 Dom0 is not yet finished, I've been trying the current code on
>different hardware, and found that with pre-Haswell Intel hardware PVHv2 Dom0
>completely freezes the box when calling iommu_hwdom_init in dom0_
On Mon, Apr 17, 2017 at 08:47:48AM +0100, Roger Pau Monné wrote:
>On Mon, Apr 17, 2017 at 07:32:45AM +0800, Chao Gao wrote:
>> On Fri, Apr 14, 2017 at 04:34:41PM +0100, Roger Pau Monné wrote:
>> >Hello,
>> >
>> >Although PVHv2 Dom0 is not yet finished, I
On Mon, Apr 17, 2017 at 09:38:54AM +0100, Roger Pau Monné wrote:
>On Mon, Apr 17, 2017 at 09:03:12AM +0800, Chao Gao wrote:
>> On Mon, Apr 17, 2017 at 08:47:48AM +0100, Roger Pau Monné wrote:
>> >On Mon, Apr 17, 2017 at 07:32:45AM +0800, Chao Gao wrote:
>> >> On F
On Mon, Apr 17, 2017 at 11:38:33AM +0100, Roger Pau Monné wrote:
>On Mon, Apr 17, 2017 at 10:49:45AM +0800, Chao Gao wrote:
>> On Mon, Apr 17, 2017 at 09:38:54AM +0100, Roger Pau Monné wrote:
>> >On Mon, Apr 17, 2017 at 09:03:12AM +0800, Chao Gao wrote:
>> >> On M
On Mon, Apr 17, 2017 at 01:21:01PM +0100, Roger Pau Monné wrote:
>On Mon, Apr 17, 2017 at 01:12:27PM +0800, Chao Gao wrote:
>[...]
>> It works. I can test for you when you send out a formal patch.
>
>Thanks for the testing, will send formal patch shortly.
>
>Have you be
On Mon, Apr 17, 2017 at 01:57:10PM +0100, Roger Pau Monné wrote:
>On Mon, Apr 17, 2017 at 01:47:47PM +0800, Chao Gao wrote:
>> On Mon, Apr 17, 2017 at 01:21:01PM +0100, Roger Pau Monné wrote:
>> >On Mon, Apr 17, 2017 at 01:12:27PM +0800, Chao Gao wrote:
>> >[...]
>>
n order to fix this add a base_gsi field to each hvm_vioapic struct, in order
>to store the base GSI for each emulated IO APIC. For PVH Dom0 those values are
>populated based on the hardware ones.
>
>Signed-off-by: Roger Pau Monné
>Reported-by: Chao
On Tue, Apr 18, 2017 at 02:24:05PM +0800, Tian, Kevin wrote:
>> From: Gao, Chao
>> Sent: Monday, April 17, 2017 4:14 AM
>>
>> On Tue, Apr 11, 2017 at 02:21:07AM -0600, Jan Beulich wrote:
>> On 11.04.17 at 02:59, wrote:
>> 3. Like what we do in struct irq_guest_action_t, can we limit the
>> m
On Tue, Apr 18, 2017 at 02:13:36AM -0600, Jan Beulich wrote:
On 16.04.17 at 22:13, wrote:
>> 3. Like what we do in struct irq_guest_action_t, can we limit the
>> maximum of entry we support in the list. With this approach, during
>> domain creation, we calculate the available entries and comp
n order to fix this add a base_gsi field to each hvm_vioapic struct, in order
>to store the base GSI for each emulated IO APIC. For PVH Dom0 those values are
>populated based on the hardware ones.
>
>Signed-off-by: Roger Pau Monné
>Reported-by: Chao Gao
Test this version a
APIC registers are
initialized, exactly like the result of a reset. This patch
introduces a new function lapic_INIT() and replaces the wrongly used
lapic_reset().
Signed-off-by: Chao Gao
---
HVM guest can't enable x2apic as XENFEAT_hvm_pirqs is exposed to it.
Why we have this restriction? As a con
On Wed, Apr 19, 2017 at 02:48:57AM -0600, Jan Beulich wrote:
On 18.04.17 at 23:51, wrote:
>> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>> and APIC ID are preserved when handling INIT signal,
LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
mode is unreasonable. This patch also doesn't reset LDR when handling INIT
signal in x2APIC mode.
Signed-off-by: Chao Gao
---
v2:
- rename vlapic_INIT to vlapic_do_init
- reset APIC to xAPIC mode in vlapic_reset()
- constify the str
On Wed, Apr 19, 2017 at 08:17:14AM -0600, Jan Beulich wrote:
On 19.04.17 at 08:40, wrote:
>> @@ -1257,7 +1257,12 @@ void vlapic_reset(struct vlapic *vlapic)
>> }
>> vlapic_set_reg(vlapic, APIC_ICR, 0);
>> vlapic_set_reg(vlapic, APIC_ICR2,0);
>> -vlapic_set_reg(vlapi
On Wed, Apr 19, 2017 at 03:41:41PM +0800, Chao Gao wrote:
>>> -vlapic->hw.apic_base_msr = (MSR_IA32_APICBASE_ENABLE |
>>> -APIC_DEFAULT_PHYS_BASE);
>>> +vlapic->hw.apic_base_msr |= APIC_DEFAULT_PHYS_BASE;
>>
>>
unction vlapic_do_init() and replaces the
wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
in vlapic_reset().
Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
mode is unreasonable. This patch also doesn't reset LDR when handling INIT
signal i
nd APIC base address
>> in vlapic_reset().
>>
>> Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
>> mode is unreasonable. This patch also doesn't reset LDR when handling INIT
>> signal in x2APIC mode.
>>
>> Signed-off-by: Ch
mode and base address in vlapic_reset()
>>>>
>>>> This patch introduces a new function vlapic_do_init() and replaces the
>>>> wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
>>>> in vlapic_reset().
>>>>
>>&
es a new function vlapic_do_init() and replaces the
>> > wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
>> > in vlapic_reset().
>> >
>> > Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
>> > mode is
PING...
Please give some comments. I think this bug should be fixed in Xen 4.9.
On Fri, Apr 07, 2017 at 11:24:16AM +0800, Chao Gao wrote:
>When injecting periodic timer interrupt in vmx_intr_assist(), multiple read
>operation is operated during one event delivery and incur to inconsistent
Kevin, thanks for your reply.
On Fri, Apr 21, 2017 at 06:56:39PM +0800, Tian, Kevin wrote:
>> From: Gao, Chao
>> Sent: Friday, April 7, 2017 11:24 AM
>>
>> When injecting periodic timer interrupt in vmx_intr_assist(), multiple read
>> operation is operated during one event delivery and incur to i
On Fri, Apr 21, 2017 at 10:00:16PM +0800, Tian, Kevin wrote:
>btw I'm thinking whether adding lock in vmx_intr_assist is
>necessary... Can you think whether below option may
>work?
>
>Do lock protection within pt_update_irq. Make sure vector
>not changed between setting vIRR and finding pt_irq_vect
This patch intruduces a 'refcnt' field in vmx_pi_blocking to track
the reference count of 'pi_desc' of the vCPU. And change this field
every time we re-program one IRTE.
Signed-off-by: Chao Gao
---
xen/arch/x86/hvm/vmx/vmx.c | 29
xen
e%20length%20of%20the%20list%20depends;#422567
[3]
https://lists.gt.net/xen/devel/472749?search_string=enable%20vt-d%20pi%20by%20default;#472749
Chao Gao (4):
xentrace: add TRC_HVM_VT_D_PI_BLOCK
VT-d PI: Randomly Distribute entries to all online pCPUs' pi blocking
list
VT-d PI: Ad
xpands the
arch_vcpu_block(), removing some restrictions expressed by
assertions and handling the target vCPU according to its state and
its PI blocking list lock (v->arch.hvm_vmx.pi_blocking.lock).
Signed-off-by: Chao Gao
---
xen/arch/x86/hvm/vmx/vmx.c | 21 ++---
xen/drivers/pa
r random pCPU) but notification comes in time, thus the vcpu
goes back to running station -> VM-entry (we should set NSDT again,
reverting the change we make to NSDT in vmx_vcpu_block())
Signed-off-by: Chao Gao
---
xen/arch/x86/hvm/vmx/vmx.c | 36 +---
1 file changed
This patch adds TRC_HVM_VT_D_PI_BLOCK to track adding one entry to
the per-pcpu blocking list. Also introduce a 'counter' to track
the number of entries in the list.
Signed-off-by: Chao Gao
---
tools/xentrace/formats | 1 +
xen/arch/x86/hvm/vmx/vmx.c | 10 +-
x
On Wed, Apr 26, 2017 at 02:19:22AM -0600, Jan Beulich wrote:
On 26.04.17 at 02:52, wrote:
>> Patch 2/4 randomly distritbutes entries (vCPUs) among all oneline
>> pCPUs, which can theoretically decrease the maximum of #entry
>> in the list by N times. N is #pCPU.
>
>Why randomly? Shouldn't cur
On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote:
>On 26/04/17 01:52, Chao Gao wrote:
>> VT-d PI introduces a per-pCPU blocking list to track the blocked vCPU
>> running on the pCPU. Theoretically, there are 32K domain on single
>> host, 128 vCPUs per domain. If
ther vCPUs changing the value we are interest in.
Thus, provide a -locked variant of hvm_isa_irq_assert() to avoid
deadlock.
Signed-off-by: Chao Gao
---
This patch is to fix a user triggerable assertion failure. I think it should
be fixed in 4.9.
---
v2:
- only use hold irq_lock in pt_update_ir
On Thu, Apr 27, 2017 at 10:44:26AM +0100, George Dunlap wrote:
>On Thu, Apr 27, 2017 at 1:43 AM, Chao Gao wrote:
>> On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote:
>>>On 26/04/17 01:52, Chao Gao wrote:
>>>> VT-d PI introduces a per-pCPU blocking
ling
>> vmx_intr_assist(). The latching operation should be protected by
>> irq_lock to prevent other vCPUs changing the value we are interest in.
>> Thus, provide a -locked variant of hvm_isa_irq_assert() to avoid
>> deadlock.
>>
>> Signed-off-by: Chao Gao
>&
On Fri, Apr 28, 2017 at 02:36:11AM -0600, Jan Beulich wrote:
On 27.04.17 at 04:47, wrote:
>> When injecting periodic timer interrupt in vmx_intr_assist(),
>> multi-read operations are done during one event delivery. For
>> example, if a periodic timer interrupt is from PIT, when set the
>> co
On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote:
>On 26/04/17 01:52, Chao Gao wrote:
>> I compared the maximum of #entry in one list and #event (adding entry to
>> PI blocking list) with and without the three latter patches. Here
&
On Wed, May 03, 2017 at 04:21:27AM -0600, Jan Beulich wrote:
>>>> On 03.05.17 at 12:08, wrote:
>> On 02/05/17 06:45, Chao Gao wrote:
>>> On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote:
>>>> On 26/04/17 01:52, Chao Gao wrote:
>>>>
On Mon, May 08, 2017 at 02:39:25AM -0600, Jan Beulich wrote:
>>>> On 08.05.17 at 18:15, wrote:
>> On Wed, May 03, 2017 at 04:21:27AM -0600, Jan Beulich wrote:
>>>>>> On 03.05.17 at 12:08, wrote:
>>>> On 02/05/17 06:45, Chao Gao wrote:
>>>&
On Mon, May 08, 2017 at 03:24:47AM -0600, Jan Beulich wrote:
>(Chao Gao got lost from the recipients list again; re-adding)
>
>>>> On 08.05.17 at 11:13, wrote:
>> On 08/05/17 17:15, Chao Gao wrote:
>>> On Wed, May 03, 2017 at 04:21:27AM -0600, Jan Beulich wr
This patch intruduces a 'refcnt' field in vmx_pi_blocking to track
the reference count of 'pi_desc' of the vCPU. And change this field
every time we re-program one IRTE.
Signed-off-by: Chao Gao
---
xen/arch/x86/hvm/vmx/vmx.c | 29
xen
rupt%20core%20logic%20handling;#422661
[2]
https://lists.gt.net/xen/devel/422567?search_string=%20The%20length%20of%20the%20list%20depends;#422567
[3]
https://lists.gt.net/xen/devel/472749?search_string=enable%20vt-d%20pi%20by%20default;#472749
Chao Gao (5):
xentrace: add TRC_HVM_PI_LIST_ADD
This number is used to calculate how many hvm vcpu on a pcpu on average.
Signed-off-by: Chao Gao
---
xen/common/domain.c | 8
xen/include/xen/sched.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index b22aacc..d433d9e 100644
This patch adds TRC_HVM_PI_LIST_ADD to track adding one entry to
the per-pcpu blocking list. Also introduce a 'counter' to track
the number of entries in the list.
Signed-off-by: Chao Gao
---
tools/xentrace/formats | 1 +
xen/arch/x86/hvm/vmx/vmx.c | 12 +++-
x
another pCPU) but notification comes in time, thus the vcpu
goes back to running station -> VM-entry (we should set NSDT again,
reverting the change we make to NSDT in vmx_vcpu_block())
Signed-off-by: Chao Gao
---
xen/arch/x86/hvm/vmx/vmx.c | 78 +-
1
xpands the
arch_vcpu_block(), removing some restrictions expressed by
assertions and handling the target vCPU according to its status and
its PI blocking list lock (v->arch.hvm_vmx.pi_blocking.lock).
Signed-off-by: Chao Gao
---
xen/arch/x86/hvm/vmx/vmx.c | 20 +---
xen/drivers/pa
On Thu, May 11, 2017 at 12:37:37PM +0100, Wei Liu wrote:
>On Thu, May 11, 2017 at 12:35:11PM +0100, Wei Liu wrote:
>> On Thu, May 11, 2017 at 02:04:09PM +0800, Chao Gao wrote:
>> > This number is used to calculate how many hvm vcpu on a pcpu on average.
>> >
&
ack
>> the number of entries in the list.
>>
>> Signed-off-by: Chao Gao
>> ---
>> @@ -119,6 +120,9 @@ static void vmx_vcpu_block(struct vcpu *v)
>> */
>> ASSERT(old_lock == NULL);
>>
>> +atomic_inc(&per_cpu(vmx_pi_bloc
gt; another pCPU) but notification comes in time, thus the vcpu
>> goes back to running station -> VM-entry (we should set NSDT again,
>> reverting the change we make to NSDT in vmx_vcpu_block())
>>
>> Signed-off-by: Chao Gao
>> ---
>> xen/arch/x86/hvm/vmx/vmx.c | 78
On Mon, May 15, 2017 at 04:48:47PM +0100, George Dunlap wrote:
>On Thu, May 11, 2017 at 7:04 AM, Chao Gao wrote:
>> Currently, a blocked vCPU is put in its pCPU's pi blocking list. If
>> too many vCPUs are blocked on a given pCPU, it will incur that the list
>> grow
weird thing.
Could give me some suggestion to debug this problem?
Or, are there some bugs in this patch?
Thanks
Chao
---8<---
From 01c10aa7edcded99017d88ac4a7fff19168f132d Mon Sep 17 00:00:00 2001
From: Chao Gao
Date: Wed, 26 Apr 2017 03:39:06 +0800
Subject: [PATCH 1/3] VT-d PI: track the v
On Fri, May 19, 2017 at 06:53:39PM +0800, Chao Gao wrote:
>Hi, George.
>
>Per your suggesion, I tried to add some code to xenalyze.c to analyze
>some newly added events. To have more understanding, you can read the
>patch at the bottom. In this patch, I try to count how many times a
s://lists.gt.net/xen/devel/472749?search_string=enable%20vt-d%20pi%20by%20default;#472749
Chao Gao (3):
VT-d PI: track the vcpu number in pi blocking list
vcpu: track hvm vcpu number on the system
VT-d PI: restrict the vcpu number on a given pcpu
tools/xentrace/formats | 3 +
tools
This number is used to calculate how many hvm vcpu on a pcpu on average.
This counting is x86 specific.
Signed-off-by: Chao Gao
---
xen/arch/x86/domain.c| 10 ++
xen/include/asm-x86/domain.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/xen/arch/x86/domain.c b/xen
context would not be checked.
Signed-off-by: Chao Gao
---
tools/xentrace/formats | 3 +
tools/xentrace/xenalyze.c | 154 +---
xen/arch/x86/hvm/vmx/vmx.c | 33 +++--
xen/include/asm-x86/hvm/trace.h | 1 +
xen/include/public/trace.h
another pCPU) but notification comes in time, thus the vcpu
goes back to running station -> VM-entry (we should set NSDT again,
reverting the change we make to NSDT in vmx_vcpu_block())
Signed-off-by: Chao Gao
---
xen/arch/x86/hvm/vmx/vmx.c | 70 +-
1
tions: from x2APIC mode to xAPIC Mode, from disabled mode
to invalid state (EN=0, EXTD=1) are disabled).
Signed-off-by: Chao Gao
---
xen/arch/x86/hvm/vlapic.c| 6 ++
xen/include/asm-x86/hvm/vlapic.h | 3 +++
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/vla
On Wed, May 31, 2017 at 02:06:50AM -0600, Jan Beulich wrote:
On 31.05.17 at 09:46, wrote:
>> --- a/xen/arch/x86/hvm/vlapic.c
>> +++ b/xen/arch/x86/hvm/vlapic.c
>> @@ -1003,14 +1003,12 @@ bool_t vlapic_msr_set(struct vlapic *vlapic,
>> uint64_t value)
>> }
>> else
>>
On Wed, May 31, 2017 at 03:15:28AM -0600, Jan Beulich wrote:
On 31.05.17 at 10:56, wrote:
>> On Wed, May 31, 2017 at 02:06:50AM -0600, Jan Beulich wrote:
>> On 31.05.17 at 09:46, wrote:
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1003,14 +1003,12 @@
tions: from x2APIC mode to xAPIC Mode, from disabled mode
to invalid state (EN=0, EXTD=1) are disabled).
Signed-off-by: Chao Gao
---
v2:
- Modify macro vlapic_xapic_mode()
---
xen/arch/x86/hvm/vlapic.c| 6 ++
xen/include/asm-x86/hvm/vlapic.h | 4
2 files changed, 6 insertions(+),
From the context calling pi_desc_init(), we can conclude the current
implementation of VT-d PI depends on CPU-side PI. If we disable APICv
but enable VT-d PI explicitly in xen boot command line, we would get
an assertion failure.
This patch disables VT-d PI when APICv is disabled and adds some
rel
related description to docs.
Signed-off-by: Chao Gao
---
v2:
- add missing S-o-b
- comments changes
- change bool_t to bool and move 'opt_apicv_enabled' declaration to vmcs.h
---
docs/misc/xen-command-line.markdown | 6 --
xen/arch/x86/hvm/vmx/vmcs.c | 2 +-
xen/drivers/passt
On Wed, Jun 07, 2017 at 06:31:18AM -0600, Jan Beulich wrote:
On 07.06.17 at 11:29, wrote:
>> @@ -2266,8 +2267,10 @@ int __init intel_vtd_setup(void)
>> * We cannot use posted interrupt if X86_FEATURE_CX16 is
>> * not supported, since we count on this feature to
>>
Hope
this is acceptable.
Signed-off-by: Chao Gao
---
v3:
- check relevant bit directly other than checking the apicv option
- add sample of 'xl dmesg'
v2:
- add missing S-o-b
- comments changes
- change bool_t to bool and move 'opt_apicv_enabled' declaration to vmcs.h
-
On Fri, Jun 09, 2017 at 02:43:30AM -0600, Jan Beulich wrote:
On 09.06.17 at 08:22, wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -351,6 +351,13 @@ static int vmx_init_vmcs_config(void)
>>|| !(_vmx_vmexit_control & VM_EXIT_ACK_INTR_ON_EXIT)
finding CPU-side PI won't be enabled.
It is safe for this is done before this flag starts taking effect. Also
take this chance to remove the useless check of "acknowledge interrupt on
exit", which is a minimal requirement which has been checked earlier.
Signed-off-by: Chao Gao
---
v4:
rated endpoint when
searching VT-d unit.
Reported-by: Crawford, Eric R
Signed-off-by: Chao Gao
---
xen/drivers/passthrough/pci.c | 28 +++-
xen/drivers/passthrough/vtd/dmar.c | 7 ++-
xen/drivers/passthrough/vtd/intremap.c | 1 +
xen/drivers/passt
+ Eric
On Fri, Jun 16, 2017 at 02:48:39PM +0800, Chao Gao wrote:
>The problem is a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
>we would wrongly use 00:00.0 to search VT-d unit.
>
>To search VT-d unit for a VF, the BDF of the PF is used. And If the
>PF is an Extended
On Fri, Jun 16, 2017 at 09:52:11AM -0600, Jan Beulich wrote:
On 16.06.17 at 08:48, wrote:
>> The problem is a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
>> we would wrongly use 00:00.0 to search VT-d unit.
>>
>> To search VT-d unit for a VF, the BDF of the PF is used. And If the
>> P
On Mon, Jun 19, 2017 at 01:43:25AM -0600, Jan Beulich wrote:
On 19.06.17 at 08:33, wrote:
>> On Fri, Jun 16, 2017 at 09:52:11AM -0600, Jan Beulich wrote:
>> On 16.06.17 at 08:48, wrote:
The problem is a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
we would wrongly use 00:
the real BDF should be used.
This patch introduces a new field, pf_is_extfn, in struct
pci_dev_info, to indicate whether the physical function is an extended
function. The new field helps to generate correct BDF to search VT-d
unit.
Reported-by: Crawford, Eric R
Tested-by: Crawford, Eric R
Signed
This number is used to calculate the average vcpus per pcpu ratio.
Signed-off-by: Chao Gao
Acked-by: Jan Beulich
---
v4:
- move the place we increase/decrease the hvm vcpu number to
hvm_vcpu_{initialise, destory}
---
xen/arch/x86/hvm/hvm.c| 6 ++
xen/include/asm-x86/hvm/hvm.h
f the pcpu where the vcpu is running exceeds
the limit which is the average vcpus per pcpu ratio plus a constant.
If no, the vcpu is added to this pcpu's pi blocking list. Otherwise,
another online pcpu is chosen to accept the vcpu.
Signed-off-by: Chao Gao
---
v5:
- Introduce a function to
s.gt.net/xen/devel/472749?search_string=enable%20vt-d%20pi%20by%20default;#472749
Chao Gao (4):
VT-d PI: track the number of vcpus on pi blocking list
x86/vcpu: track hvm vcpu number on the system
VT-d PI: restrict the number of vcpus in a given pcpu's PI blocking
list
xentrace: add
This patch adds a field, counter, in struct vmx_pi_blocking_vcpu to track
how many entries are on the pi blocking list.
Signed-off-by: Chao Gao
---
v5:
- introduce two functions for adding or removing vcpus from pi blocking list.
- check the sanity of vcpu count on pi blocking list
v4:
- non
In order to analyze PI blocking list operation frequence and obtain
the list length, add some relevant events to xentrace and some
associated code in xenalyze.
Signed-off-by: Chao Gao
---
v5:
- Put pi list operation under HW events and get rid of ASYNC stuff
- generate scatterplot of pi list
On Wed, Aug 16, 2017 at 09:17:46AM +0100, Roger Pau Monné wrote:
>on wed, aug 16, 2017 at 01:12:24pm +0800, chao gao wrote:
>> the problem is for a vf of rc integrated pf (e.g. pf's bdf is
>> 00:02.0), we would wrongly use 00:00.0 to search vt-d unit.
>>
>> if a
On Thu, Aug 17, 2017 at 01:28:21PM +0100, Wei Liu wrote:
>On Thu, Aug 17, 2017 at 12:32:17PM +0100, Wei Liu wrote:
>> On Wed, Aug 09, 2017 at 04:34:10PM -0400, Lan Tianyu wrote:
>> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
>> > index f54fd49..94c9196 100644
>> > --- a/tools/l
info to indicate
whether the PF of this VF is an extended function. The field helps to use
correct BDF to search VT-d unit.
Reported-by: Crawford, Eric R
Signed-off-by: Chao Gao
---
v7:
- Drop Eric's tested-by
- Change commit message to be clearer
- Re-use VF's is_extfn field
- ac
used.
>>
>> This patch introduces a new field, pf_is_extfn, in struct
>> pci_dev_info, to indicate whether the physical function is an extended
>> function. The new field helps to generate correct BDF to search VT-d
>> unit.
>>
>> Reported-by: Crawford,
On Tue, Aug 22, 2017 at 08:29:58AM +0100, Roger Pau Monné wrote:
>On Tue, Aug 22, 2017 at 05:52:04AM +0800, Chao Gao wrote:
>> When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are
>> under
>> the scope of the same VT-d unit as the &#x
On Tue, Aug 22, 2017 at 06:43:49AM -0600, Jan Beulich wrote:
On 21.08.17 at 23:52, wrote:
>> --- a/xen/include/xen/pci.h
>> +++ b/xen/include/xen/pci.h
>> @@ -39,6 +39,10 @@
>> #define PCI_SBDF3(s,b,df) s) & 0x) << 16) | PCI_BDF2(b, df))
>>
>> struct pci_dev_info {
>> +/*
>> +
On Wed, Aug 23, 2017 at 08:31:51AM +0100, Roger Pau Monné wrote:
>On Wed, Aug 23, 2017 at 01:20:13AM -0600, Jan Beulich wrote:
>> >>> On 23.08.17 at 09:16, wrote:
>> > On Wed, Aug 23, 2017 at 09:05:14AM +0800, Chao Gao wrote:
>> >> On Tue, Aug 22, 2017
On Wed, Aug 23, 2017 at 02:04:24AM -0600, Jan Beulich wrote:
On 23.08.17 at 03:05, wrote:
>> Strictly speaking, the VF can be an extended function. The definition is
>> within ARI device (in this kind of device, device field is treated as an
>> extension of function number) and function numbe
On Wed, Aug 23, 2017 at 09:01:07AM +0100, Roger Pau Monné wrote:
>On Wed, Aug 23, 2017 at 02:46:08PM +0800, Chao Gao wrote:
>> On Wed, Aug 23, 2017 at 08:31:51AM +0100, Roger Pau Monné wrote:
>> >On Wed, Aug 23, 2017 at 01:20:13AM -0600, Jan Beulich wrote:
>> >> &g
On Thu, Aug 24, 2017 at 02:22:47AM -0600, Jan Beulich wrote:
On 24.08.17 at 10:01, wrote:
>>> From: Tian, Kevin
>>> Sent: Thursday, August 24, 2017 3:22 PM
>>>
>>> > From: Gao, Chao
>>> > Sent: Tuesday, August 22, 2017 5:52 AM
>>> >
>>> > When SR-IOV is enabled, 'Virtual Functions' of a 'Ph
On Thu, Aug 24, 2017 at 04:17:32AM -0600, Jan Beulich wrote:
On 24.08.17 at 12:12, wrote:
>> On Thu, Aug 24, 2017 at 04:07:40AM -0600, Jan Beulich wrote:
>>> >>> On 24.08.17 at 11:47, wrote:
>>> > @@ -438,6 +439,22 @@ int pt_irq_create_bind(
>>> > pi_update_irte(vcpu ? &vcpu->ar
info to indicate
whether the PF of this VF is an extended function. The field helps to use
correct BDF to search VT-d unit.
Reported-by: Crawford, Eric R
Signed-off-by: Chao Gao
---
v8:
- use "conceptually wrong", instead of "a corner case" in commit message
- check 'is_
From 3aa2541108f28cfdf0f3bf47ddae9b762b73b532 Mon Sep 17 00:00:00 2001
From: Chao Gao
Date: Mon, 7 Aug 2017 04:50:04 +0800
Subject: [PATCH v9] VT-d: use correct BDF for VF to search VT-d unit
When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under
the
I have sent out a new version, let's skip this one.
Thanks
Chao
On Fri, Aug 25, 2017 at 12:17:15PM +0800, Chao Gao wrote:
>When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under
>the scope of the same VT-d unit as the 'Physical Functi
PF of this VF is
an extended function. The field helps to use correct BDF to search VT-d unit.
Reported-by: Crawford, Eric R
Signed-off-by: Chao Gao
---
- RESEND for the previous email has no subject.
v9:
- check 'is_virtfn' first in pci_add_device() to avoid potential error
On Wed, Aug 23, 2017 at 01:19:41PM +0100, Roger Pau Monné wrote:
>On Wed, Aug 09, 2017 at 04:34:26PM -0400, Lan Tianyu wrote:
>> From: Chao Gao
>>
>> Wrap some useful status in a new structure hvm_hw_vvtd, following
>> the customs of vlapic, vioapic and etc. Provide t
On Wed, Aug 23, 2017 at 12:51:27PM +0100, Roger Pau Monné wrote:
>On Wed, Aug 09, 2017 at 04:34:24PM -0400, Lan Tianyu wrote:
>> From: Chao Gao
>>
>> Interrupt translation faults are non-recoverable fault. When faults
> ^
On Wed, Aug 23, 2017 at 11:41:25AM +0100, Roger Pau Monné wrote:
>On Wed, Aug 09, 2017 at 04:34:22PM -0400, Lan Tianyu wrote:
>> From: Chao Gao
>>
>> Introduce a new binding relationship and provide a new interface to
>> manage the new relationship.
>>
>>
On Fri, Aug 25, 2017 at 03:00:32AM -0600, Jan Beulich wrote:
>>>> On 25.08.17 at 08:35, wrote:
>> On Wed, Aug 23, 2017 at 01:19:41PM +0100, Roger Pau Monné wrote:
>>>On Wed, Aug 09, 2017 at 04:34:26PM -0400, Lan Tianyu wrote:
>>>> From: Chao Gao
>
t;> is conceptually wrong w/o checking whether PF is an extended function and
>> would lead to match VFs of a RC endpoint to a wrong VT-d unit.
>>
>> This patch uses VF's 'is_extfn' field to indicate whether the PF of this VF
>> is
>> an extended functi
an extended function and
>>>> would lead to match VFs of a RC endpoint to a wrong VT-d unit.
>>>>
>>>> This patch uses VF's 'is_extfn' field to indicate whether the PF of this
>>>> VF
>>>> is
>>>> an extended functio
27;is_extfn' field and uses this field to
indicate whether the PF of this VF is an extended function. The field
helps to use correct BDF to search VT-d unit.
Reported-by: Crawford, Eric R
Signed-off-by: Chao Gao
---
v10:
- move setting vf's is_extfn closer to the place where we set
'Extended Funcion'.
>> But it is conceptually wrong w/o checking whether PF is an extended
>> function and would lead to match VFs of a RC integrated PF to a wrong
>> VT-d unit.
>>
>> This patch overrides VF 'is_extfn' field and uses this field to
On Wed, Aug 30, 2017 at 10:00:49AM -0600, Jan Beulich wrote:
On 16.08.17 at 07:14, wrote:
>> @@ -100,6 +101,24 @@ void vmx_pi_per_cpu_init(unsigned int cpu)
>> spin_lock_init(&per_cpu(vmx_pi_blocking, cpu).lock);
>> }
>>
>> +static void vmx_pi_add_vcpu(struct pi_blocking_vcpu *pbv,
>>
On Thu, Aug 31, 2017 at 01:42:53AM -0600, Jan Beulich wrote:
On 31.08.17 at 00:57, wrote:
>> On Wed, Aug 30, 2017 at 10:00:49AM -0600, Jan Beulich wrote:
>> On 16.08.17 at 07:14, wrote:
@@ -100,6 +101,24 @@ void vmx_pi_per_cpu_init(unsigned int cpu)
spin_lock_init(&per_cpu
On Tue, Aug 29, 2017 at 08:33:25AM +0100, Roger Pau Monne wrote:
>On Mon, Aug 28, 2017 at 06:18:13AM +, Tian, Kevin wrote:
>> > From: Roger Pau Monne [mailto:roger@citrix.com]
>> > Sent: Friday, August 25, 2017 9:59 PM
>> >
>> > On Fri, Aug 25, 2017 at 06:25:36AM -0600, Jan Beulich wrote:
1 - 100 of 294 matches
Mail list logo
