Re: [Xen-devel] Enabling VT-d PI by default

> 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: > >> As you know, with VT-d PI enabled, hardware can directly deliver external > >> interrupts to guest without any

Re: [Xen-devel] PVH Dom0 Intel IOMMU issues

> From: Roger Pau Monné [mailto:roger@citrix.com] > Sent: Friday, April 14, 2017 11:35 PM > > 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

Re: [Xen-devel] [PATCH v3] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again

> From: David Woodhouse [mailto:dw...@infradead.org] > Sent: Monday, February 6, 2017 7:33 PM > > On Fri, 2017-01-27 at 10:36 -0500, Konrad Rzeszutek Wilk wrote: > > . snip .. > > > > > > > > > > > Signed-off-by: David Woodhouse > > > Reviewed-by: Jan Beulich

Re: [Xen-devel] [PATCH 3/3] x86/HVM: don't uniformly report "MMIO" for various forms of failed emulation

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, April 13, 2017 10:54 PM > > This helps distingushing the call paths leading there. > > Signed-off-by: Jan Beulich > Reviewed-by: Kevin Tian

Re: [Xen-devel] [PATCH 2/3] VMX: don't blindly enable descriptor table exiting control

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, April 13, 2017 10:53 PM > > This is an optional feature and hence we should check for it before > use. > > Signed-off-by: Jan Beulich > Reviewed-by: Kevin Tian

Re: [Xen-devel] [PATCH v2] VT-d: correct a comment and remove an useless if() statement

> From: Gao, Chao > Sent: Wednesday, April 12, 2017 1:35 PM > > Fix two flaws in the patch (93358e8e VT-d: introduce update_irte to update > irte safely): > 1. Expand a comment in update_irte() to make it clear that VT-d hardware > doesn't update IRTE and software can't update IRTE behind us

Re: [Xen-devel] [PATCH v12 6/7] VT-d: introduce update_irte to update irte safely

> From: Gao, Chao > Sent: Thursday, April 6, 2017 8:30 AM > > We used structure assignment to update irte which was non-atomic when > the > whole IRTE was to be updated. It is unsafe when a interrupt happened > during > update. Furthermore, no bug or warning would be reported when this >

Re: [Xen-devel] [PATCH v12 3/7] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt

> From: Gao, Chao > Sent: Thursday, April 6, 2017 8:30 AM > > msi_msg_to_remap_entry() is buggy when the live IRTE is in posted format. It > wrongly inherits the 'im' field meaning the IRTE is in posted format but > updates all the other fields to remapping format. > > There are also two

Re: [Xen-devel] [PATCH] x86/HVM: don't leak PFEC_implict to guests

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, April 6, 2017 10:28 PM > > Doing so may not only confuse them, but will - on VMX - lead to > VMRESUME failures. Add respective ASSERT()s where the fields get set > to guard against future similar issues (or - in the restore case - >

Re: [Xen-devel] [PATCH v12 5/6] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.

> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: Thursday, April 6, 2017 11:54 PM > > After an ioreq server has unmapped, the remaining p2m_ioreq_server > entries need to be reset back to p2m_ram_rw. This patch does this > asynchronously with the current p2m_change_entry_type_global()

Re: [Xen-devel] [PATCH v12 2/6] x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to an ioreq server.

> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: Thursday, April 6, 2017 11:54 PM > > Previously, p2m_ioreq_server is used to write-protect guest ram > pages, which are tracked with ioreq server's rangeset. However, > number of ram pages to be tracked may exceed the upper limit of >

Re: [Xen-devel] [PATCH v2] x86/vpmu_intel: Handle SMT consistently for programmable and fixed counters

> From: Mohit Gambhir [mailto:mohit.gamb...@oracle.com] > Sent: Thursday, April 6, 2017 3:50 AM > > The patch introduces a macro FIXED_CTR_CTRL_ANYTHREAD_MASK and uses > it > to mask .Anythread bit for all counter in IA32_FIXED_CTR_CTRL MSR in all > versions of Intel Arhcitectural Performance

Re: [Xen-devel] [PATCH v2] x86/monitor: add support for descriptor access events

> From: Adrian Pop [mailto:a...@bitdefender.com] > Sent: Tuesday, April 4, 2017 5:58 PM > > Adds monitor support for descriptor access events (reads & writes of > IDTR/GDTR/LDTR/TR) for the x86 architecture (VMX and SVM). > > Signed-off-by: Adrian Pop Reviewed-by: Kevin

Re: [Xen-devel] [PATCH] x86/vpmu_intel: Handle SMT consistently for programmable and fixed counters

> From: Mohit Gambhir [mailto:mohit.gamb...@oracle.com] > Sent: Friday, March 31, 2017 10:46 PM > > This patch masks .AnyThread bits in IA32_FIXED_CTR_CTRL MSR for all > versions of Intel Arhcitectural Performance Monitoring. Note that > .AnyThread bit (21) is already masked in IA32_PERFEVTSELx

Re: [Xen-devel] [PATCH for 4.9 2/6] x86/hvm: Correct long mode predicate

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Saturday, April 1, 2017 3:51 AM > > hvm_long_mode_enabled() tests for EFER.LMA, which is specifically different > to > EFER.LME. > > Rename it to match its behaviour, and have it strictly return a boolean value > (although all its

Re: [Xen-devel] [PATCH v11 5/6] VT-d: introduce update_irte to update irte safely

> From: Gao, Chao > Sent: Wednesday, March 29, 2017 1:12 PM > > We used structure assignment to update irte which was non-atomic when > the > whole IRTE was to be updated. It is unsafe when a interrupt happened > during > update. Furthermore, no bug or warning would be reported when this >

Re: [Xen-devel] [PATCH v11 2/6] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt

> From: Gao, Chao > Sent: Wednesday, March 29, 2017 1:12 PM > > msi_msg_to_remap_entry() is buggy when the live IRTE is in posted format. It > wrongly inherits the 'im' field meaning the IRTE is in posted format but > updates all the other fields to remapping format. > > There are also two

Re: [Xen-devel] [PATCH v11 1/6] passthrough: don't migrate pirq when it is delivered through VT-d PI

> From: Chao Gao > Sent: Wednesday, March 29, 2017 1:12 PM > > When a vCPU migrated to another pCPU, pt irqs binded to this vCPU also > needed migration. When VT-d PI is enabled, interrupt vector will be recorded > to a main memory resident data-structure and a notification whose > destination is

Re: [Xen-devel] [PATCH v11 0/6] VMX: Properly handle pi descriptor and per-cpu blocking list

> From: Gao, Chao > Sent: Wednesday, March 29, 2017 1:12 PM > > The current VT-d PI related code may operate incorrectly in the following > scenarios: > 1. When VT-d PI is enabled, neen't migrate pirq which is using VT-d PI during neen't -> needn't > vCPU migration. Patch [1/6] solves this by

Re: [Xen-devel] [PATCH v3 3/9] x86/vmx: expose LMCE feature via guest MSR_IA32_FEATURE_CONTROL

> From: Zhang, Haozhong > Sent: Thursday, March 30, 2017 2:20 PM > > If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then set LMCE and > LOCK bits in guest MSR_IA32_FEATURE_CONTROL. Intel SDM requires those > bits are set before SW can enable LMCE. > > Signed-off-by: Haozhong Zhang

Re: [Xen-devel] [PATCH v3 2/8] x86/hvm: introduce hvm_domain_irq macro

> From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: Wednesday, March 29, 2017 10:47 PM > > Introduce a macro to get a pointer to the hvm_irq for a HVM domain. No > functional change. > > Signed-off-by: Roger Pau Monné Reviewed-by: Kevin Tian

Re: [Xen-devel] Legacy PCI interrupt {de}assertion count

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, March 27, 2017 4:00 PM > > >>> On 24.03.17 at 17:54, wrote: > > As I understand it, for level triggered legacy PCI interrupts Xen sets > > up a timer in order to perform the EOI if the guest takes too long in >

Re: [Xen-devel] [PATCH v9 4/5] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.

> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: Wednesday, March 22, 2017 6:12 PM > > On 3/22/2017 4:10 PM, Tian, Kevin wrote: > >> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com] > >> Sent: Tuesday, March 21, 2017 10:53 AM > >>

Re: [Xen-devel] [PATCH v9 2/5] x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to an ioreq server.

> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: Wednesday, March 22, 2017 6:13 PM > > On 3/22/2017 3:49 PM, Tian, Kevin wrote: > >> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com] > >> Sent: Tuesday, March 21, 2017

Re: [Xen-devel] [PATCH v10 4/6] VT-d: introduce update_irte to update irte safely

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, March 16, 2017 6:29 PM > > >>> On 15.03.17 at 23:39, wrote: > > On Wed, Mar 15, 2017 at 10:48:25AM -0600, Jan Beulich wrote: > > On 15.03.17 at 06:11, wrote: > >>> +/* > >>> +

Re: [Xen-devel] [xen-unstable test] 106504: regressions - FAIL

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, March 24, 2017 4:18 PM > > >>> On 24.03.17 at 08:48, wrote: > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: Wednesday, March 22, 2017 8:48 PM > >> > >> > 3. We read RTE 3 times. 1st happens when we

Re: [Xen-devel] [xen-unstable test] 106504: regressions - FAIL

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, March 22, 2017 8:48 PM > > > 3. We read RTE 3 times. 1st happens when we set vIRR. 2nd happens when > > pt_update_irq() returns. 3rd happens in pt_intr_post(). If guest > > changes the vector in RTE during the window, it will also

Re: [Xen-devel] [PATCH v9 5/5] x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, March 22, 2017 4:54 PM > > >>> On 22.03.17 at 09:28, wrote: > >> From: Yu Zhang > >> Sent: Tuesday, March 21, 2017 10:53 AM > >> --- a/xen/arch/x86/hvm/dm.c > >> +++ b/xen/arch/x86/hvm/dm.c > >> @@ -385,16

Re: [Xen-devel] [RFC PATCH 1/23] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities

> From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: Wednesday, March 22, 2017 3:57 AM > > > > > diff --git a/xen/common/Makefile b/xen/common/Makefile index > > 0fed30b..b58de63 100644 > > --- a/xen/common/Makefile > > +++ b/xen/common/Makefile > > @@ -60,6 +60,7 @@ obj-y += vm_event.o > >

Re: [Xen-devel] [PATCH v10 1/6] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt

> From: Gao, Chao > Sent: Wednesday, March 22, 2017 8:19 AM > > On Wed, Mar 22, 2017 at 01:59:19PM +0800, Tian, Kevin wrote: > >> From: Gao, Chao > >> Sent: Wednesday, March 15, 2017 1:11 PM > >> > >> Currently, msi_msg_to_remap_entry is b

Re: [Xen-devel] [PATCH v9 5/5] x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

> From: Yu Zhang > Sent: Tuesday, March 21, 2017 10:53 AM > > After an ioreq server has unmapped, the remaining p2m_ioreq_server > entries need to be reset back to p2m_ram_rw. This patch does this > synchronously by iterating the p2m table. > > The synchronous resetting is necessary because we

Re: [Xen-devel] [PATCH v9 4/5] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.

> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: Tuesday, March 21, 2017 10:53 AM > > After an ioreq server has unmapped, the remaining p2m_ioreq_server > entries need to be reset back to p2m_ram_rw. This patch does this > asynchronously with the current p2m_change_entry_type_global()

Re: [Xen-devel] [PATCH v9 2/5] x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to an ioreq server.

> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: Tuesday, March 21, 2017 10:53 AM > > A new DMOP - XEN_DMOP_map_mem_type_to_ioreq_server, is added to let > one ioreq server claim/disclaim its responsibility for the handling of guest > pages with p2m type p2m_ioreq_server. Users of

Re: [Xen-devel] [PATCH v10 6/6] passthrough/io: Fall back to remapping interrupt when we can't use VT-d PI

> From: Gao, Chao > Sent: Wednesday, March 15, 2017 1:11 PM > > The current logic of using VT-d pi is when guest configurates the pirq's > destination vcpu to a single vcpu, the according IRTE is updated to posted > format. If the destination of the pirq is multiple vcpus, we just use >

Re: [Xen-devel] [PATCH v10 4/6] VT-d: introduce update_irte to update irte safely

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, March 16, 2017 6:29 PM > > >>> On 15.03.17 at 23:39, wrote: > > On Wed, Mar 15, 2017 at 10:48:25AM -0600, Jan Beulich wrote: > > On 15.03.17 at 06:11, wrote: > >>> +/* > >>> +

Re: [Xen-devel] [PATCH v10 1/6] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt

> From: Gao, Chao > Sent: Wednesday, March 15, 2017 1:11 PM > > Currently, msi_msg_to_remap_entry is buggy when the live IRTE is in posted > format. Straightforwardly, we can let caller specify which format of IRTE they > want update to. But the problem is current callers are not aware of the >

Re: [Xen-devel] [PATCH v9 8/8] VT-d: Add copy_irte_{to, from}_irt for updating irte

> From: Gao, Chao > Sent: Monday, February 27, 2017 9:46 AM > > We used structure assignment to update irte which was not safe when a a -> an > interrupt happend during update. It is better to update IRTE atomically happend -> happened > through cmpxchg16b(). When cmpxchg16b is not supported,

Re: [Xen-devel] [PATCH v2 4/6] iommu: Remove dependency on __LINE__ for release builds

> From: Ross Lagerwall [mailto:ross.lagerw...@citrix.com] > Sent: Thursday, March 9, 2017 1:47 AM > > When using LivePatch, use of __LINE__ can generate spurious changes in > functions due to embedded line numbers. For release builds with LivePatch > enabled, remove the use of these line numbers

Re: [Xen-devel] [PATCH 3/4] x86emul: correct handling of FPU insns faulting on memory write

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, March 13, 2017 7:05 PM > > When an FPU instruction with a memory destination fails during the memory > write, it should not affect FPU register state. Due to the way we emulate FPU > (and SIMD) instructions, we can only guarantee this

Re: [Xen-devel] [PATCH v1 3/3] x86/vvmx: add a shadow vmcs check to vmlaunch

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, March 13, 2017 6:52 PM > > Intel SDM states that if the current VMCS is a shadow VMCS, VMFailInvalid > occurs and control passes to the next instruction. > > Implement such behaviour for nested vmlaunch. > > Signed-off-by:

Re: [Xen-devel] [PATCH v1 2/3] x86/vvmx: correct nested shadow VMCS handling

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, March 13, 2017 6:52 PM > > Currently xen always sets the shadow VMCS-indicator bit on nested vmptrld > and always clears it on nested vmclear. This behavior is wrong when the > guest loads a shadow VMCS: shadow bit will be

Re: [Xen-devel] [PATCH v1 1/3] x86/vvmx: add mov-ss blocking check to vmentry

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, March 13, 2017 6:52 PM > > Intel SDM states that if there is a current VMCS and there is MOV-SS blocking, > VMFailValid occurs and control passes to the next instruction. > > Implement such behaviour for nested vmlaunch and

Re: [Xen-devel] [PATCH v9 1/8] VMX: Permanently assign PI hook vmx_pi_switch_to()

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, March 03, 2017 6:49 PM > > >>> On 03.03.17 at 09:29, wrote: > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: Wednesday, March 01, 2017 3:42 PM > >> Sounds good to me (read: Reviewed-by: Jan Beulich

Re: [Xen-devel] [PATCH v9 3/8] VMX: Properly handle pi when all the assigned devices are removed

> From: Gao, Chao > Sent: Monday, February 27, 2017 9:46 AM > > From: Feng Wu > > This patch handles some corner cases when the last assigned device > is removed from the domain. In this case we should carefully handle > pi descriptor and the per-cpu blocking list, to make

Re: [Xen-devel] [PATCH v9 1/8] VMX: Permanently assign PI hook vmx_pi_switch_to()

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, March 01, 2017 3:42 PM > > >>> On 01.03.17 at 01:01, wrote: > > On Tue, Feb 28, 2017 at 09:43:09AM -0700, Jan Beulich wrote: > > On 27.02.17 at 02:45, wrote: > >>> ---

Re: [Xen-devel] [PATCH v1 2/2] x86/vvmx: add vmcs id check into vmptrld emulation

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Wednesday, March 01, 2017 5:14 PM > > If a guest will do vmptrld with an incorrect vmcs id: > > (XEN) Xen BUG at .../git/upstream/xen/xen/include/asm/hvm/vmx/vmx.h:333 > (XEN) [ Xen-4.9-unstable x86_64 debug=y Tainted:H

Re: [Xen-devel] [PATCH v1 1/2] x86/vvmx: check vmcs address in vmread/vmwrite

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, March 01, 2017 11:40 PM > > >>> On 01.03.17 at 16:23, wrote: > > On Wed, 2017-03-01 at 07:28 -0700, Jan Beulich wrote: > >> > > > On 01.03.17 at 15:22, wrote: > >> > > >> > On

Re: [Xen-devel] [PATCH 1/2] x86/hvm: Don't raise #GP behind the emulators back for CR accesses

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Thursday, March 02, 2017 11:00 PM > > hvm_set_cr{0,4}() are reachable from the emulator, but use > hvm_inject_hw_exception() directly. > > Alter the API to make the callers of hvm_set_cr{0,3,4}() responsible for > raising #GP, and

Re: [Xen-devel] [PATCH v3] x86/apicv: Enhance posted-interrupt processing

> From: Gao, Chao > Sent: Thursday, March 02, 2017 12:28 PM > > On Thu, Mar 02, 2017 at 02:41:55AM -0700, Jan Beulich wrote: > On 02.03.17 at 02:49, wrote: > >> +if ( cpu != smp_process_id() ) > > > >Did you not even build test this patch? I don't think the

Re: [Xen-devel] [PATCH v2] x86/apicv: enhance posted-interrupt processing

> From: Gao, Chao > Sent: Wednesday, March 01, 2017 2:24 PM > > > Good point. I ignore v->processor maybe change. I have thought over > __vmx_deliver_posted_interrupt() again and want to share you my > opinion. > First of all, __vmx_deliver_posted_interrupt() is to let the target > vCPU sync

Re: [Xen-devel] Virtual Interrupt Delivery

> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > Sent: Thursday, March 02, 2017 4:36 AM > > On Mon, Feb 27, 2017 at 09:13:29PM +0300, Dmitry Rockosov wrote: > > Hi guys, > > > > Do you know when *recognized* Virtual Interrupt on VM-Entry will be > > delivered if Virtual-Interrupt

Re: [Xen-devel] [PATCH v2 1/3] x86: remove PVHv1 code

> -Original Message- > From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: Wednesday, March 01, 2017 1:40 AM > To: xen-de...@lists.xenproject.org > Cc: Roger Pau Monne; Ian Jackson; Wei Liu; Elena Ufimtseva; Jan Beulich; > Andrew Cooper; > Paul Durrant

Re: [Xen-devel] [PATCH v4 2/2] x86/vpmu: Disable VPMU if guest's CPUID indicates no PMU support

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Wednesday, March 01, 2017 11:07 PM > > When toolstack overrides Intel CPUID leaf 0xa's PMU version with an > invalid value VPMU should not be available to the guest. > > Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH 8/8] x86/VMX: switch away from temporary 32-bit register names

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Tuesday, February 28, 2017 9:39 PM > > Signed-off-by: Jan Beulich > Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH 2/3] x86: remove has_hvm_container_{domain/vcpu}

> From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: Friday, February 24, 2017 11:13 PM > > It is now useless since PVHv1 is removed and PVHv2 is a HVM domain from Xen's > point of view. > > Signed-off-by: Roger Pau Monné Reviewed-by: Kevin Tian

Re: [Xen-devel] [PATCH v3 2/2] x86/vpmu: Disable VPMU if guest's CPUID indicates no PMU support

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Thursday, February 23, 2017 2:24 AM > > When toolstack overrides Intel CPUID leaf 0xa's PMU version with an > invalid value VPMU should not be available to the guest. > > Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v3 1/2] x86/vpmu: Add get/put_vpmu() and VPMU_AVAILABLE

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Thursday, February 23, 2017 2:24 AM > > vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf > for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED > bit. This is problematic: > * For HVM guests

Re: [Xen-devel] [PATCH v2] iommu: Elaborate the usage of RMRR specification on the command line

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, February 24, 2017 4:56 PM > > >>> On 23.02.17 at 18:03, wrote: > > As some users have suggested, elaborate the usage of RMRR specification > > on the command line, and provide a usage example. > > > > Also,

Re: [Xen-devel] [PATCH v3 3/3] x86/vmx: fix vmentry failure with TSX bits in LBR

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Thursday, February 23, 2017 5:33 PM > > During VM entry, H/W will automatically load guest's MSRs from MSR-load > area in the same way as they would be written by WRMSR. > > However, under the following conditions: > > 1. LBR

Re: [Xen-devel] [PATCH v3 1/3] x86/vmx: introduce vmx_find_msr()

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Thursday, February 23, 2017 5:33 PM > > Modify vmx_add_msr() to use a variation of insertion sort algorithm: > find a place for the new entry and shift all subsequent elements before > insertion. > > The new vmx_find_msr() exploits

Re: [Xen-devel] [PATCH v2 1/3] x86/vmx: introduce vmx_find_msr()

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Wednesday, February 22, 2017 4:38 PM > > > > > > > -for ( idx = 0; idx < *msr_count; idx++ ) > > > +for ( idx = 0; (*msr_area)[idx].index <= msr && idx < *msr_count; > > > idx++ ) > > > > risk of out-of-boundary access. > >

Re: [Xen-devel] [PATCH] xen/x86: ensure copying to L1 guest in update_runstate_area()

> From: Zhang, Haozhong > Sent: Wednesday, February 22, 2017 10:21 AM > > > > > > > > And why is this HAP-specific? > > > > > > > IIUC, nested HVM relies on HAP. > > For nested SVM, I find the following check in hvmop_set_param(): > case HVM_PARAM_NESTEDHVM: > if ( cpu_has_svm &&

Re: [Xen-devel] [PATCH v2 1/3] x86/vpmu: Add get/put_vpmu() and VPMU_AVAILABLE

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Tuesday, February 21, 2017 10:10 PM > > On 02/21/2017 03:09 AM, Tian, Kevin wrote: > >> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > >> Sent: Saturday, February 18, 2017 1:40 AM

Re: [Xen-devel] [PATCH v2 3/3] x86/vmx: fix vmentry failure with TSX bits in LBR

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Tuesday, February 21, 2017 7:25 PM > > On 21/02/17 09:13, Tian, Kevin wrote: > >> @@ -2618,6 +2630,56 @@ static const struct lbr_info > >> *last_branch_msr_get(void) > >>

Re: [Xen-devel] [PATCH] x86/apicv: enhance posted-interrupt processing

> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com] > Sent: Tuesday, February 21, 2017 12:12 PM > > On February 21, 2017 11:07 AM, Tian, Kevin wrote: > >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com] > >> Sent: Tuesday, February 21, 2017 10:49 AM > >

Re: [Xen-devel] [PATCH v2 2/3] x86/vmx: optimize vmx_read/write_guest_msr()

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Friday, February 17, 2017 11:43 PM > > Replace linear scan with vmx_find_msr(). This way the time complexity > of searching for required MSR reduces from linear to logarithmic. > > Signed-off-by: Sergey Dyasli

Re: [Xen-devel] [PATCH v2 3/3] x86/vmx: fix vmentry failure with TSX bits in LBR

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Friday, February 17, 2017 11:43 PM > > During VM entry, H/W will automatically load guest's MSRs from MSR-load > area in the same way as they would be written by WRMSR. > > However, under the following conditions: > > 1. LBR

Re: [Xen-devel] [PATCH v2 2/3] x86/vpmu: Disable VPMU if guest's CPUID indicates no PMU support

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Saturday, February 18, 2017 1:40 AM > > When toolstack overrides CPUID leaf 0xa values (on Intel processors) > VPMU should not be available to the guest. only when override with an invalid version? otherwise ok to me.

Re: [Xen-devel] [PATCH v2 1/3] x86/vpmu: Add get/put_vpmu() and VPMU_AVAILABLE

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Saturday, February 18, 2017 1:40 AM > > vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf > for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED > bit. This is problematic: > * For HVM guests

Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, February 17, 2017 4:21 PM > > I think the commit description is pretty clear. Especially this part > > "This could have the nice side effect of allowing to use "iommu=off" > even when x2APIC was pre-enabled by the BIOS (in which

[Xen-devel] [PATCH] MAINTAINERS: Update VT-d maintainers

MAINTAINERS: Update VT-d maintainers Feng just left Intel. So remove him from the list. Signed-off-by: Kevin Tian diff --git a/MAINTAINERS b/MAINTAINERS index 6f7ffeb..f14f844 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -215,7 +215,6 @@ F: xen/include/asm-x86/tboot.h

Re: [Xen-devel] [PATCH v2] x86/VMX: sanitize VM86 TSS handling

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, February 17, 2017 8:04 PM > > The present way of setting this up is flawed: Leaving the I/O bitmap > pointer at zero means that the interrupt redirection bitmap lives > outside (ahead of) the allocated space of the TSS. Similarly

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com] > Sent: Monday, February 20, 2017 8:04 PM > > On February 13, 2017 4:21 PM, Tian, Kevin wrote: > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: Wednesday, February 08, 2017 4:52 PM > >&g

Re: [Xen-devel] [PATCH] x86/apicv: enhance posted-interrupt processing

> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com] > Sent: Tuesday, February 21, 2017 10:49 AM > > On February 20, 2017 4:24 PM, Chao Gao wrote: > >On Mon, Feb 20, 2017 at 11:25:29AM +, Xuquan (Quan Xu) wrote: > >>On February 18, 2017 12:33 AM, Jan Beulich wrote: > >> On 17.02.17 at

Re: [Xen-devel] [PATCH 1/4] x86/vmx: Don't leak host syscall MSR state into HVM guests

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, February 20, 2017 7:17 PM > To: Tian, Kevin > Cc: Jan Beulich; Suravee Suthikulpanit; Nakajima, Jun; Xen-devel; Boris > Ostrovsky > Subject: Re: [PATCH 1/4] x86/vmx: Don't leak host syscall MSR state

Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0

> From: Tian, Kevin > Sent: Friday, February 17, 2017 11:35 AM > > >> > > >> Or wait - do you have the same issue if you use > > >> "iommu=no,no-intremap"? In which case the problem would be > > >> that "iommu=no" should c

Re: [Xen-devel] [PATCH v2 2/2] x86: package up context switch hook pointers

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, February 16, 2017 7:16 PM > > They're all solely dependent on guest type, so we don't need to repeat > all the same three pointers in every vCPU control structure. Instead use > static const structures, and store pointers to them in

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, February 16, 2017 8:36 PM > > >>> On 16.02.17 at 13:27, wrote: > > On 16/02/17 11:15, Jan Beulich wrote: > >> When __context_switch() is being bypassed during original context > >> switch handling, the

Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, February 16, 2017 5:32 PM > > >>> On 15.02.17 at 20:30, wrote: > > On Wed, Feb 15, 2017 at 3:03 AM, Jan Beulich wrote: > > On 15.02.17 at 00:21, wrote:

Re: [Xen-devel] [PATCH v3] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Thursday, February 16, 2017 11:46 PM > > XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be > lower than the real maxphysaddr, to avoid overflowing the superpage shadow > backpointer. > > However, plenty

Re: [Xen-devel] [PATCH 1/4] x86/vmx: Don't leak host syscall MSR state into HVM guests

> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew Cooper > Sent: Tuesday, February 14, 2017 4:19 PM > > On 14/02/2017 08:04, Tian, Kevin wrote: > >> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew > Cooper > >> Sent

Re: [Xen-devel] [PATCH 1/4] x86/vmx: Don't leak host syscall MSR state into HVM guests

> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew Cooper > Sent: Tuesday, February 14, 2017 3:59 PM > > On 14/02/2017 02:52, Tian, Kevin wrote: > >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > >> Sent: Monday, February 13, 2017

Re: [Xen-devel] [PATCH 1/5] x86/hvm: Rework HVM_HCALL_invalidate handling

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, February 13, 2017 9:04 PM > > Sending an invalidation to the device model is an internal detail of > completing the hypercall; callers should not need to be responsible for it. > Drop HVM_HCALL_invalidate entirely and call

Re: [Xen-devel] [PATCH 4/4] x86/vmx: Drop vmx_msr_state infrastructure

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, February 13, 2017 10:33 PM > > To avoid leaking host MSR state into guests, guest LSTAR, STAR and > SYSCALL_MASK state is unconditionally loaded when switching into guest > context. > > Attempting to dirty-track the state

Re: [Xen-devel] [PATCH 3/4] x86/vmx: Remove vmx_save_host_msrs() and host_msr_state

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, February 13, 2017 10:32 PM > > A pcpu's LSTAR, STAR and SYSCALL_MASK MSRs are unconditionally switched when > moving in and out of HVM vcpu context. Two of these values are compile time > constants, and the third is

Re: [Xen-devel] [PATCH 1/4] x86/vmx: Don't leak host syscall MSR state into HVM guests

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, February 13, 2017 10:32 PM > > hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to be > restored when switching into guest context. It should never have been part of > the migration state to start with,

Re: [Xen-devel] [PATCH v4 3/3] x86/vvmx: correctly emulate VMREAD

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, February 13, 2017 10:21 PM > > There is an issue with the original __vmread() in nested vmx mode: > emulation of a guest's VMREAD with invalid arguments leads to BUG(). > > Fix this by using vmread_safe() and reporting any

Re: [Xen-devel] [PATCH v4 2/3] x86/vvmx: correctly emulate VMWRITE

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, February 13, 2017 10:21 PM > > There is an issue with the original __vmwrite() in nested vmx mode: > emulation of a guest's VMWRITE with invalid arguments leads to BUG(). > > Fix this by using vmwrite_safe() and reporting

Re: [Xen-devel] [PATCH v4 1/3] x86/vmx: introduce VMX_INSN_SUCCEED

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, February 13, 2017 10:21 PM > > The new value corresponds to VMsucceed status of VMX instructions. > This will replace usage of literal zeroes in related functions. > > Update vmfail(), vmread_safe() and vmwrite_safe(). > >

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

> From: Tian, Kevin > Sent: Monday, February 13, 2017 4:21 PM > > > From: Jan Beulich [mailto:jbeul...@suse.com] > > Sent: Wednesday, February 08, 2017 4:52 PM > > > > >>> On 08.02.17 at 09:27, <xuqu...@huawei.com> wrote: > > > As

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, February 08, 2017 4:52 PM > > >>> On 08.02.17 at 09:27, wrote: > > Assumed vCPU is in guest_mode.. > > When apicv is enabled, hypervisor calls vmx_deliver_posted_intr(), then > >

Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, February 10, 2017 5:36 PM > > >>> On 07.02.17 at 00:32, wrote: > > Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has > > added a assertion that intack.vector is the highest priority

Re: [Xen-devel] [PATCH 3/3] x86: Adjust which files need vpmu.h

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Monday, February 13, 2017 10:30 AM > > asm-x86/vmcs.h doesn't need it while asm-x86/domain.h does. > > Signed-off-by: Boris Ostrovsky > --- > CC: Jun Nakajima > CC: Kevin

Re: [Xen-devel] [PATCH v2 1/2] x86/vmx: Introduce a bitfield structure for EPT_VIOLATION EXIT_QUALIFICATIONs

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, February 08, 2017 6:43 PM > > This results in rather more readable code. No functional change. > > All fields currently specified are included, but commented out as no support > for their use is present. > >

Re: [Xen-devel] [PATCH v6] x86/hvm: add vcpu parameter to guest memory copy function

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, February 08, 2017 9:37 PM > > >>> On 07.02.17 at 18:35, wrote: > > Current __hvm_copy assumes that the destination memory belongs to the > > current > > vcpu, but this is not always the case since for PVHv2

Re: [Xen-devel] [PATCH v3 2/4] x86/vmx: improve vmread_safe()

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Wednesday, February 08, 2017 6:10 PM > > The original function doesn't distinguish between Valid and Invalid > VMfails. Improved function returns error code depending on the outcome: > > VMsucceed: 0 > VMfailValid: VM

Re: [Xen-devel] [PATCH v3 1/4] x86/vmx: introduce vmwrite_safe()

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Wednesday, February 08, 2017 6:10 PM > > Any fail during the original __vmwrite() leads to BUG() which can be > easily exploited from a guest in the nested vmx mode. > > The new function returns error code depending on the outcome:

Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()

> From: Gao, Chao > Sent: Wednesday, February 08, 2017 8:12 AM > > On Tue, Feb 07, 2017 at 09:18:56AM -0700, Jan Beulich wrote: > On 07.02.17 at 08:28, wrote: > >> On Tue, Feb 07, 2017 at 06:46:16AM -0700, Jan Beulich wrote: > >> On 07.02.17 at 07:32,

Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()

> From: Wei Liu [mailto:wei.l...@citrix.com] > Sent: Tuesday, February 07, 2017 6:05 PM > > On Tue, Feb 07, 2017 at 02:51:54AM -0700, Jan Beulich wrote: > > >>> On 07.02.17 at 00:32, wrote: > > > Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") > > >

Re: [Xen-devel] [PATCH] x86/vvmx: Improvements to INVEPT instruction handling

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Tuesday, February 07, 2017 12:55 AM > > * Latch current once at the start. > * Avoid the memory operand read for INVEPT_ALL_CONTEXT. Experimentally, this >is how hardware behaves, and avoids an unnecessary pagewalk. > *

<    1   2   3   4   5   6   7   8   9   >