add Feng as the new maintainer of VT-d stuff
Signed-off-by: Yang Zhang
---
MAINTAINERS |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 759de1b..eb48f77 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -193,8 +193,8 @@ F: xen/arch/x86/tboot.
Liuqiming (John) wrote on 2015-10-10:
>
> On 2015/10/10 14:32, Zhang, Yang Z wrote:
>> Zhang, Yang Z wrote on 2015-09-24:
>>> Liuqiming (John) wrote on 2015-09-24:
>>>>
>>>> On 2015/9/24 11:25, Zhang, Yang Z wrote:
>>>> it completed,
Liuyingdong wrote on 2015-10-31:
> Hi All
>
> We encountered a blue screen problem when live migrate
> Win8.1/Win2012R2 64bit VM from V3 processor to non-V3 processor
> sandbox, KVM does not has this problem.
>
> After looking into the MSR capabilities, we found XEN hypervisor
> exposed bit 39 an
Jan Beulich wrote on 2015-10-15:
On 15.10.15 at 10:52, wrote:
>> Jan Beulich wrote on 2015-10-15:
>> On 15.10.15 at 09:28, wrote:
The premise for a misbehaving guest to impact the system is that
the IOMMU is buggy which takes long time to complete the invalidation.
In othe
Jan Beulich wrote on 2015-10-15:
On 15.10.15 at 09:28, wrote:
>> Jan Beulich wrote on 2015-10-15:
>> On 15.10.15 at 03:03, wrote:
Jan Beulich wrote on 2015-10-14:
> As long as the multi-millisecond spins aren't going to go away by
> other means, I think conversion to async m
Jan Beulich wrote on 2015-10-15:
On 15.10.15 at 03:03, wrote:
>> Jan Beulich wrote on 2015-10-14:
>>> As long as the multi-millisecond spins aren't going to go away by
>>> other means, I think conversion to async mode is ultimately unavoidable.
>>
>> I am not fully agreed. I think the time t
Jan Beulich wrote on 2015-10-14:
On 14.10.15 at 07:12, wrote:
>> Jan Beulich wrote on 2015-10-13:
>> On 13.10.15 at 07:27, wrote:
Jan Beulich wrote on 2015-10-12:
On 12.10.15 at 03:42, wrote:
>> So, my suggestion is that we can rely on user to not assign the
>> ATS
Jan Beulich wrote on 2015-10-13:
On 13.10.15 at 07:27, wrote:
>> Jan Beulich wrote on 2015-10-12:
>> On 12.10.15 at 03:42, wrote:
So, my suggestion is that we can rely on user to not assign the
ATS device if hypervisor says it cannot support such device. For
example, if hy
Jan Beulich wrote on 2015-10-13:
On 13.10.15 at 07:28, wrote:
>> Acked-by: Yang Zhang
>
> Thanks. What about patch 1?
Done!
I think I have acked it. But seems I forget to do it.
Best regards,
Yang
___
Xen-devel mailing list
Xen-devel@lists.x
Jan Beulich wrote on 2015-09-29:
> ... allowing to suppress a confusing messeage combination: When
> ACPI_DMAR_X2APIC_OPT_OUT is set, so far we first logged a message that
> IR could not be enabled (hence not using x2APIC), followed by one
> indicating successful initialization of IR (if no othe
Jan Beulich wrote on 2015-10-12:
On 10.10.15 at 08:30, wrote:
>> Jan Beulich wrote on 2015-09-29:
>>> --- a/xen/drivers/passthrough/vtd/intremap.c
>>> +++ b/xen/drivers/passthrough/vtd/intremap.c
>>> @@ -143,7 +143,7 @@ static void set_hpet_source_id(unsigned
>>> set_ire_sid(ire, SVT_VER
Jan Beulich wrote on 2015-10-12:
On 12.10.15 at 03:42, wrote:
>> According the discussion and suggestion you made in past several
>> weeks, obviously, it is not an easy task. So I am wondering whether
>> it is worth to do it since:
>> 1. ATS device is not popular. I only know one NIC from Myr
Xu, Quan wrote on 2015-09-16:
> Introduction
>
>
>VT-d code currently has a number of cases where completion of
> certain operations is being waited for by way of spinning. The
> majority of instances use that variable indirectly through
> IOMMU_WAIT_OP() macro , allowing for loop
Zhang, Yang Z wrote on 2015-09-24:
> Liuqiming (John) wrote on 2015-09-24:
>>
>>
>> On 2015/9/24 11:25, Zhang, Yang Z wrote:
>> it completed, the following vmentry will pick up the pending interrupt.
>> If you send the ipi unconditionally, actually it is
Jan Beulich wrote on 2015-09-29:
> With x2APIC requiring iommu_supports_eim() to return true, we can
> adjust a few conditonals such that both it and
> platform_supports_x2apic() can be marked __init. For the latter as
> well as for platform_supports_intremap() also change the return types
> to boo
Jan Beulich wrote on 2015-09-28:
> GFN zero is a valid address, and hence may need invalidation done for
> it just like for any other GFN.
>
> Signed-off-by: Jan Beulich
Acked-by: Yang Zhang
> ---
> The comment right before the respective dmar_writeq() confuses me:
> What "first" TLB reg does
Xu, Quan wrote on 2015-09-25:
> Signed-off-by: Quan Xu
Though the patch is simple, the necessary description still is required, like:
Bit 0:29 in Fault Event Control Register are " Reserved and Preserved",
software cannot
write 0 to it unconditionally. Software must preserve the value read for
Liuqiming (John) wrote on 2015-09-24:
>
>
> On 2015/9/24 11:25, Zhang, Yang Z wrote:
>> Liuqiming (John) wrote on 2015-09-24:
>>> On 2015/9/23 21:41, Zhang, Yang Z wrote:
>>>> Hanweidong (Randy) wrote on 2015-09-23:
>>>>> Zhang, Yang Z wrote
Liuqiming (John) wrote on 2015-09-24:
> On 2015/9/23 21:41, Zhang, Yang Z wrote:
>> Hanweidong (Randy) wrote on 2015-09-23:
>>>
>>> Zhang, Yang Z wrote on ent: 2015年9月23日 11:51:
>>>> VCPU_KICK_SOFTIRQ when post interrupt to vm.
>>>>
>>&g
Hanweidong (Randy) wrote on 2015-09-23:
>
>
> Zhang, Yang Z wrote on ent: 2015年9月23日 11:51:
>> VCPU_KICK_SOFTIRQ when post interrupt to vm.
>>
>> Zhang, Yang Z wrote on 2015-09-08:
>>> Liuqiming (John) wrote on 2015-09-08:
>>>> Ok, I will tr
Jan Beulich wrote on 2015-09-23:
On 23.09.15 at 11:15, wrote:
>> Jan Beulich wrote on 2015-09-23:
>> On 23.09.15 at 05:50, wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1678,8 +1678,9 @@ static void
__vmx_deliver_posted_interrupt(struct
George Dunlap wrote on 2015-09-23:
> On Wed, Sep 23, 2015 at 8:42 AM, Jan Beulich wrote:
> On 23.09.15 at 05:50, wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -1678,8 +1678,9 @@ static void
> __vmx_deliver_posted_interrupt(struct vcpu *v)
>>> {
>
Jan Beulich wrote on 2015-09-23:
On 23.09.15 at 05:50, wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -1678,8 +1678,9 @@ static void __vmx_deliver_posted_interrupt(struct
> vcpu *v)
>> {
>> unsigned int cpu = v->processor;
>> -if ( !
Zhang, Yang Z wrote on 2015-09-08:
> Liuqiming (John) wrote on 2015-09-08:
>> Ok, I will try to explain, correct me if I got anything wrong:
>>
>> The problem here is not interrupts lost but interrupts not delivered
>> in time.
>>
>> there are basically
Andrew Cooper wrote on 2015-09-18:
> On 18/09/15 12:40, Zhang, Yang Z wrote:
>> Jan Beulich wrote on 2015-09-18:
>>>>>> "Zhang, Yang Z" 09/18/15 2:29 AM >>>
>>>> Zhang, Yang Z wrote on 2015-09-08:
>>>> I have a quick c
Jan Beulich wrote on 2015-09-18:
>>>> "Zhang, Yang Z" 09/18/15 2:29 AM >>>
>> Zhang, Yang Z wrote on 2015-09-08:
>> I have a quick check on current code. I am curious that is current Xen
>> preemptive?
>>
>> Also, when return
Zhang, Yang Z wrote on 2015-09-08:
> Liuqiming (John) wrote on 2015-09-08:
>> Ok, I will try to explain, correct me if I got anything wrong:
>>
>> The problem here is not interrupts lost but interrupts not delivered
>> in time.
>>
>> there are basically
Liuqiming (John) wrote on 2015-09-08:
> Ok, I will try to explain, correct me if I got anything wrong:
>
> The problem here is not interrupts lost but interrupts not delivered in
> time.
>
> there are basically two path to inject an interrupt into VM (or vCPU to
> another vCPU):
> Path 1, the tr
Hanweidong (Randy) wrote on 2015-09-08:
>
> Jan Beulich wrote on ent: 2015年9月7日 22:46:
>> Subject: Re: [Xen-devel] [PATCH] Remove a set operation for
>> VCPU_KICK_SOFTIRQ when post interrupt to vm.
>>
> On 07.09.15 at 16:24, wrote:
>>> I believe this also has something to do with a windows g
Jan Beulich wrote on 2015-09-07:
On 07.09.15 at 15:00, wrote:
>> Jan Beulich wrote on 2015-09-07:
>>> Yang, in this context: Why does __vmx_deliver_posted_interrupt()
>>> not use cpu_raise_softirq(), instead kind of open coding it (see your
>>> d7dafa375b ["VMX: Add posted interrupt supportin
Jan Beulich wrote on 2015-09-07:
>> + * jnz .Lvmx_process_softirqs
>> + *
>> + * ..
>> + *
>> + * je .Lvmx_launch
>> + *
>> + * ..
>> + *
>> + * .Lvmx_process_softirqs:
>> + * sti
>> + * call do_softirq
>> +
elena.ufimts...@oracle.com wrote on 2015-07-07:
> From: Elena Ufimtseva
>
> Release memory allocated for scope.devices dmar units on various
> failure paths and when disabling dmar. Set device count after
> successful memory allocation, not before, in device scope parsing function.
>
> Signed-of
Jan Beulich wrote on 2015-06-18:
On 18.06.15 at 10:02, wrote:
>> When using FIO to test the performance of SSD passthroughed in vm
>> the result show that: When the apicv is on, each
>> EXIT_REASON_MSR_WRITE event spent more time than apicv is off.
>>
>> Following is the xentrace result:
>>
Jan Beulich wrote on 2015-06-18:
On 18.06.15 at 10:53, wrote:
>> Jan Beulich wrote on 2015-06-18:
>> On 18.06.15 at 10:20, wrote:
Apart from that I notice that the EXIT_REASON_EOI_INDUCED handling
also adds about the same number of ticks...
>>>
>>> Are there any other devices
Jan Beulich wrote on 2015-06-18:
On 18.06.15 at 10:20, wrote:
>> Apart from that I notice that the EXIT_REASON_EOI_INDUCED handling
>> also adds about the same number of ticks...
>
> Are there any other devices in the guest causing meaningful amounts of
> interrupts (I suppose the SSD itself
Jan Beulich wrote on 2015-06-16:
On 16.06.15 at 05:07, wrote:
>> Jan Beulich wrote on 2015-06-15:
>> On 13.06.15 at 16:44, wrote:
> On 12.06.15 at 14:47, wrote:
On 12.06.15 at 04:40, wrote:
>> I tested it by a Myri-10G Dual-Protocol NIC, which is an ATS device.
>>
Jan Beulich wrote on 2015-06-15:
On 13.06.15 at 16:44, wrote:
>>> On 12.06.15 at 14:47, wrote:
>> On 12.06.15 at 04:40, wrote:
> On 10.06.15 at 16:05, wrote:
On 03.06.15 at 09:49, wrote:
>> For Context Invalidation and IOTLB invalidation without
>> Device-
ot,
> so "Virtual Interrupt Delivery" and "Posted Interrupt Processing" works, I
> guess.
Maybe you can turn on the three features one by one(need some changes in code).
Then it will help us to know which feature really causes the problem
>
> I think the problem is
Sunguodong wrote on 2015-06-03:
> Hi,
>
> I am getting a vm stuck problem when booting a windows 7 guest on
> xen-4.6(latest version).
>
> My hvm guest: Windows 7 64bit (installed pvdriver inside, pvdriver is
> downloaded from
> 'http://wiki.univention.de/index.php?title=Installing-signed-GPLP
Liuqiming (John) wrote on 2015-06-11:
> Hi,
>
> Recently I encounter a strange performance problem with APIC virtualization.
>
> My host has Intel(R) Xeon(R) CPU E7-4890 v2 CPU installed which support
> APIC virtualization and x2apic, and there are 4 socket * 15
> cores_per_socket = 60 core avail
Jan Beulich wrote on 2015-05-11:
On 11.05.15 at 04:53, wrote:
>> Jan Beulich wrote on 2015-05-07:
>>> --- a/xen/drivers/passthrough/x86/iommu.c
>>> +++ b/xen/drivers/passthrough/x86/iommu.c
>>> @@ -59,10 +59,17 @@ int arch_iommu_populate_page_table(struc
>>> if ( has_hvm_container_do
Jan Beulich wrote on 2015-05-07:
> Handing INVALID_GFN to functions like hd->platform_ops->map_page() just
> can't do any good, and the ioreq server code results in such pages being on
> the
> list of ones owned by a guest.
>
> While - as suggested by Tim - we should use get_gfn()/put_gfn() there
Michael Dexter wrote on 2015-05-07:
>
> Hello all,
>
> I have been working with Roger Pau Monné to bring FreeBSD Dom0 support
> to a production-ready state but we appear to have hit an IOMMU issue.
>
> Hardware: Lenovo ThinkPad T420 i7-2640M CPU @ 2.80GHz with 16GB RAM.
>
> I am attaching my c
Jan Beulich wrote on 2015-05-04:
On 04.05.15 at 11:14, wrote:
>> On 04/05/2015 09:52, Jan Beulich wrote:
>> On 04.05.15 at 04:16, wrote:
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c
@@ -56,7 +56,9 @@ unsigned int get_cache_line_si
Chen, Tiejun wrote on 2015-05-04:
> Yang,
>
> Thanks for your review.
>
> On 2015/5/4 12:07, Zhang, Yang Z wrote:
>> Chen, Tiejun wrote on 2015-05-04:
>>> While initializing VT-D we should mask interrupt message generation
>>> to avoid receiving any
Chen, Tiejun wrote on 2015-05-04:
> While initializing VT-D we should mask interrupt message generation
> to avoid receiving any interrupt as pending before enable DMA
> translation, and also mask that before disable DMA engine.
>
> Signed-off-by: Tiejun Chen
> ---
> xen/drivers/passthrough/vtd/
Chen, Tiejun wrote on 2015-05-04:
> clflush is a light weight but not serializing instruction, so hence
> memory fence is necessary to make sure all load/store visible before flush
> cache line.
>
> Signed-off-by: Tiejun Chen
Acked-by: Yang Zhang
> ---
> xen/drivers/passthrough/vtd/x86/vtd.c
openlui wrote on 2015-03-28:
> Hi, all:
> I have done the same testing on hosts which support "Intel VT-d
> Shared EPT tables" today, the results show that similar problem still
> exists under xen
> 4.5 release:
>1. When we boot xen with "iommu=1, no-sharept" argument which will
> disabl
Wu, Feng wrote on 2015-03-27:
>
>
> Zhang, Yang Z wrote on 2015-03-25:
>> when vCPU is running
>>
>> Wu, Feng wrote on 2015-03-25:
>>> When a vCPU is running in Root mode and a notification event has
>>> been injected to it. we need to set VCPU
Jan Beulich wrote on 2015-03-26:
> I got repeatedly annoyed by there not getting anything logged by
> default on VT-d faults (and hence having to tell people to add extra
> command line options), and hence I think it is time to redo this code:
> Log basic fault information at guest-warning level
Wu, Feng wrote on 2015-03-25:
> When a vCPU is running in Root mode and a notification event has been
> injected to it. we need to set VCPU_KICK_SOFTIRQ for the current cpu,
> so the pending interrupt in PIRR will be synced to vIRR before VM-Exit in
> time.
Shouldn't the pending interrupt be sync
Konrad Rzeszutek Wilk wrote on 2015-03-19:
> On Wed, Mar 18, 2015 at 12:44:21PM +, Wu, Feng wrote:
>> VT-d Posted-interrupt (PI) design for XEN
>>
>> Background
>> ==
>> With the development of virtualization, there are more and more
>> device assignment requirements. However, today wh
Tian, Kevin wrote on 2015-02-04:
>> From: Li, Liang Z
>> Sent: Wednesday, February 04, 2015 11:28 AM
>>
>> Flushing cache is needed only when guest has IOMMU device, using
>> need_iommu(d) can minimize the impact to guest with device assigned,
>> since a guest may be hot plugged with a device thus
Tian, Kevin wrote on 2015-01-22:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 21, 2015 6:31 PM
>>
>>>
>>> Yes, it's true. But I still don't understand why to do the
>>> flush_all just when iommu_enable is true. Could you explain why ?
>>
>> The question you raise
Jan Beulich wrote on 2015-01-05:
Elena Ufimtseva 01/02/15 7:32 PM >>>
>> The last successful command is the reading status register of second
>> IOMMU
>> unit:
>>
>> > ./xen/drivers/passthrough/vtd/iommu.c>
>>
>> 746:sts = dmar_readl(iommu->reg, DMAR_GSTS_REG); 747:
>> dmar_writel(io
Julien Grall wrote on 2014-12-17:
> diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h index
> 5f295f3..6ace79d 100644
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -13,6 +13,7 @@
> #include #include #include
> +#include #include
>
> /* @@ -75,8 +76,19 @@ struct
Andrew Cooper wrote on 2014-12-04:
> On 04/12/14 01:50, Zhang, Yang Z wrote:
>> Konrad Rzeszutek Wilk wrote on 2014-12-03:
>>> On Wed, Dec 03, 2014 at 09:38:49AM +, Ian Campbell wrote:
>>>> On Tue, 2014-12-02 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
>>&g
Konrad Rzeszutek Wilk wrote on 2014-12-03:
> On Wed, Dec 03, 2014 at 09:38:49AM +, Ian Campbell wrote:
>> On Tue, 2014-12-02 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Nov 28, 2014 at 11:50:43AM +, Ian Campbell wrote:
On Fri, 2014-11-28 at 18:52 +0800, Liang Li wrote:
>>>
Jan Beulich wrote on 2014-11-25:
>>>> On 25.11.14 at 02:47, wrote:
>> Tim Deegan wrote on 2014-11-19:
>>> At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
>>>> Tim Deegan wrote on 2014-11-18:
>>>>> In this case, the guest is en
Tim Deegan wrote on 2014-11-19:
> At 01:29 + on 19 Nov (1416356943), Zhang, Yang Z wrote:
>> Tim Deegan wrote on 2014-11-18:
>>> In this case, the guest is entitled to _expect_ pagefaults on 1GB
>>> mappings if CPUID claims they are not supported. That sounds lik
Tim Deegan wrote on 2014-11-18:
> At 14:26 + on 18 Nov (1416317209), Ian Campbell wrote:
>> On Tue, 2014-11-18 at 11:41 +0000, Zhang, Yang Z wrote:
>>>> Hmm - this is a pitfall waiting to happen.
>>>>
>>>> In the case that there is a heterogene
Andrew Cooper wrote on 2014-11-18:
> On 18/11/14 10:14, Tim Deegan wrote:
>> At 17:25 + on 17 Nov (1416241517), Andrew Cooper wrote:
>>> On 17/11/14 17:00, Tim Deegan wrote:
At 16:40 + on 17 Nov (1416238835), Andrew Cooper wrote:
> On 17/11/14 16:30, Tim Deegan wrote:
>> At 16:
Konrad Rzeszutek Wilk wrote on 2014-11-10:
> On Mon, Nov 10, 2014 at 05:08:09AM +0000, Zhang, Yang Z wrote:
>> Konrad Rzeszutek Wilk wrote on 2014-01-16:
>>> On Mon, Jan 13, 2014 at 11:51:28AM +, Jan Beulich wrote:
>>>>>>> On 13.01.14 at 12:38, Ian Camp
Konrad Rzeszutek Wilk wrote on 2014-01-16:
> On Mon, Jan 13, 2014 at 11:51:28AM +, Jan Beulich wrote:
> On 13.01.14 at 12:38, Ian Campbell wrote:
>>> On Mon, 2014-01-13 at 11:30 +, Jan Beulich wrote:
In fact I can't see where this would be forced off:
xc_cpuid_x86.c only does
64 matches
Mail list logo
