Re: [Xen-devel] [PATCH 0/9] x86/vvmx: Read instruction operands correctly on VM exit

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Friday, October 27, 2017 1:59 AM > > On 26/10/17 18:03, Euan Harris wrote: > > decode_vmx_inst() does not read instruction operands correctly on VM > exit: > > > > * It incorrectly uses vmx_inst_info's address_size field to

Re: [Xen-devel] [PATCH 4/9] x86/vvmx: Remove unnecessary VMX operand reads

> From: Euan Harris [mailto:euan.har...@citrix.com] > Sent: Friday, October 27, 2017 1:03 AM > > * vpid is never used in nvmx_handle_invept() so there is no point in >reading it. I think you meant nvmx_handle_invvpid > > * vmptrst's operand is the memory address to which to write the

Re: [Xen-devel] [PATCH v1] x86/vvmx: don't enable vmcs shadowing for nested guests

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, October 23, 2017 5:33 PM > > Running "./xtf_runner vvmx" in L1 Xen under L0 Xen produces the > following result on H/W with VMCS shadowing: > > Test: vmxon > Failure in test_vmxon_in_root_cpl0() > Expected

Re: [Xen-devel] [PATCH v3 for-next 4/4] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN

> From: Julien Grall [mailto:julien.gr...@linaro.org] > Sent: Wednesday, November 1, 2017 10:03 PM > > Most of the users of page_to_mfn and mfn_to_page are either overriding > the macros to make them work with mfn_t or use mfn_x/_mfn because the > rest of the function use mfn_t. > > So make

Re: [Xen-devel] [PATCH V3 28/29] x86/vvtd: Add queued invalidation (QI) support

> From: Gao, Chao > Sent: Monday, October 23, 2017 4:52 PM > > On Mon, Oct 23, 2017 at 09:57:16AM +0100, Roger Pau Monné wrote: > >On Mon, Oct 23, 2017 at 03:50:24PM +0800, Chao Gao wrote: > >> On Fri, Oct 20, 2017 at 12:20:06PM +0100, Roger Pau Monné wrote: > >> >On Thu, Sep 21, 2017 at

Re: [Xen-devel] [PATCH v3 for 4.10] x86/vpt: guarantee the return value of pt_update_irq() set in vIRR or PIR

> From: Gao, Chao > Sent: Friday, October 20, 2017 8:35 AM > > pt_update_irq() is expected to return the vector number of periodic > timer interrupt, which should be set in vIRR of vlapic or in PIR. > Otherwise it would trigger the assertion in vmx_intr_assist(), please > seeing

Re: [Xen-devel] [PATCH for-next] x86/VT-x: Don't use rdmsr() to fill HOST_SYSENTER_{CS, EIP}

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Friday, October 20, 2017 10:02 PM > > These are compile-time constants, and don't need to be read back from > hardware. > > Signed-off-by: Andrew Cooper Acked-by: Kevin Tian

Re: [Xen-devel] [PATCH for-4.10 v2] passthrough/vtd: Don't DMA to the stack in queue_invalidate_wait()

> From: Tian, Kevin > Sent: Monday, October 23, 2017 3:05 PM > > > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > > Sent: Saturday, October 21, 2017 1:55 AM > > > > On 20/10/17 08:12, Jan Beulich wrote: > > >>>> On 19.10.17 at 18:22

Re: [Xen-devel] [PATCH for-4.10 v2] passthrough/vtd: Don't DMA to the stack in queue_invalidate_wait()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Saturday, October 21, 2017 1:55 AM > > On 20/10/17 08:12, Jan Beulich wrote: > On 19.10.17 at 18:22, wrote: > >> DMA-ing to the stack is generally considered bad practice. In this case, > >> if > a

Re: [Xen-devel] [PATCH for-next] x86/VT-x: Don't rewrite HOST_TR_SELECTOR on every context switch

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, October 18, 2017 1:16 AM > > TSS_ENTRY is a compile time constant, so HOST_TR_SELECTOR can be set > up during > VMCS construction and left alone thereafter, rather than rewriting it on > every > context switch. > >

Re: [Xen-devel] [PATCH] vt-d: use two 32-bit writes to update DMAR fault address registers

> From: Roger Pau Monné [mailto:roger@citrix.com] > Sent: Wednesday, September 20, 2017 4:31 PM > > On Mon, Sep 11, 2017 at 02:00:48PM +0800, Haozhong Zhang wrote: > > The 64-bit DMAR fault address is composed of two 32 bits registers > > DMAR_FEADDR_REG and DMAR_FEUADDR_REG. According to

Re: [Xen-devel] [PATCH 3/3] x86/vmx: Better description of CR4 settings outside of paged mode

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Saturday, September 30, 2017 2:31 AM > > This rearanges the logic to avoid the double !hvm_paging_enabled(v) check, > but > is otherwise identical. > > Signed-off-by: Andrew Cooper Acked-by: Kevin Tian

Re: [Xen-devel] [PATCH 2/3] x86/vmx: Don't self-recurse in vmx_update_guest_cr()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Saturday, September 30, 2017 2:31 AM > > An update to CR4 following a CR0 update can be done easily by falling > through into the CR4 case. This avoids unnecessary passes through > vmx_vmcs_{enter,exit}() and unnecessary stack

Re: [Xen-devel] [PATCH 1/3] x86/vmx: Misc cleanup to vmx_update_guest_cr()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Saturday, September 30, 2017 2:31 AM > > * Drop trailing whitespace > * Fix indendation and newlines > * Use bool where appropriate > > No functional change. > > Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH v13 1/3] x86emul: New return code for unimplemented instruction

> From: George Dunlap [mailto:george.dun...@citrix.com] > Sent: Wednesday, October 4, 2017 7:14 PM > > On 10/04/2017 12:11 PM, Jan Beulich wrote: > On 02.10.17 at 16:09, wrote: > >> On 10/02/2017 02:43 PM, George Dunlap wrote: > >>> On 09/25/2017 01:03 PM, Petre

Re: [Xen-devel] [PATCH] x86: Make use of pagetable_get_mfn() where appropriate

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, October 4, 2017 8:07 PM > > >>> On 28.09.17 at 20:36, wrote: > > ... instead of the opencoded _mfn(pagetable_get_pfn(...)) construct. > > > > Fix two overly long lines; no functional change. > > > >

Re: [Xen-devel] [PATCH for-4.9 v2] VMX: PLATFORM_INFO MSR is r/o

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, October 9, 2017 3:49 PM > > Therefore all write attempts should produce #GP, just like on real > hardware. > > Signed-off-by: Jan Beulich > Reviewed-by: Roger Pau Monné Acked-by: Kevin

Re: [Xen-devel] [PATCH v2 9/9] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN

> From: Julien Grall [mailto:julien.gr...@linaro.org] > Sent: Friday, October 6, 2017 1:42 AM > > Most of the users of page_to_mfn and mfn_to_page are either overriding > the macros to make them work with mfn_t or use mfn_x/_mfn because the > rest of the function use mfn_t. > > So make

Re: [Xen-devel] [PATCH v1 5/5] x86/msr: introduce guest_wrmsr()

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Wednesday, August 30, 2017 6:35 PM > > The new function is responsible for handling WRMSR from both HVM and > PV > guests. Currently it handles only 2 MSRs: > > MSR_INTEL_PLATFORM_INFO > MSR_INTEL_MISC_FEATURES_ENABLES > >

Re: [Xen-devel] [PATCH v1 4/5] x86/msr: introduce guest_rdmsr()

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Wednesday, August 30, 2017 6:35 PM > > The new function is responsible for handling RDMSR from both HVM and > PV > guests. Currently it handles only 2 MSRs: > > MSR_INTEL_PLATFORM_INFO > MSR_INTEL_MISC_FEATURES_ENABLES > >

Re: [Xen-devel] [PATCH v1 3/5] x86: replace arch_vcpu::cpuid_faulting with msr_vcpu_policy

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Wednesday, August 30, 2017 6:35 PM > > Since each vCPU now has struct msr_vcpu_policy, use cpuid_faulting bit > from there in current logic and remove arch_vcpu::cpuid_faulting. > > Signed-off-by: Sergey Dyasli

Re: [Xen-devel] [PATCH v1 2/5] x86/msr: introduce struct msr_vcpu_policy

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Wednesday, August 30, 2017 6:35 PM > > The new structure contains information about guest's MSRs that are > unique to each vCPU. It starts with only 1 MSR: > > MSR_INTEL_MISC_FEATURES_ENABLES > > Which currently has only 1

Re: [Xen-devel] [PATCH v1 1/5] x86/msr: introduce struct msr_domain_policy

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Wednesday, August 30, 2017 6:34 PM > > The new structure contains information about guest's MSRs that are > shared between all domain's vCPUs. It starts with only 1 MSR: > > MSR_INTEL_PLATFORM_INFO > > Which currently has only

Re: [Xen-devel] [PATCH v2 12/13] [RFC] iommu: VT-d: Squash map_pages/unmap_pages with map_page/unmap_page

this patch alone looks OK to me. but I haven't found time to review the whole series to judge whether below change is necessary. > From: Oleksandr Tyshchenko [mailto:olekst...@gmail.com] > Sent: Tuesday, September 12, 2017 10:44 PM > > Hi. > > Gentle reminder. > > On Mon, Aug 21, 2017 at 7:44

Re: [Xen-devel] [PATCH v1] x86/vvmx: add hvm_intsrc_vector support to nvmx_intr_intercept()

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Wednesday, September 13, 2017 9:01 PM > > Under the following circumstances: > > 1. L1 doesn't enable PAUSE exiting or PAUSE-loop exiting controls > 2. L2 executes PAUSE in a loop with RFLAGS.IE == 0 > > L1's PV IPI through

Re: [Xen-devel] [PATCH 08/15] xen/x86: p2m: Use typesafe gfn for the P2M callbacks get_entry and set_entry

> From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: Thursday, September 14, 2017 2:00 AM > > Signed-off-by: Julien Grall > > Cc: Jan Beulich > Cc: Andrew Cooper > Cc: Razvan Cojocaru > Cc:

Re: [Xen-devel] [PATCH] custom parameter handling fixes

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, September 14, 2017 4:57 PM > > The recent changes to their handling introduced a few false warnings, > due to checks looking at the wrong string slot. While going through all > those commits and looking for patterns similar to the

Re: [Xen-devel] [PATCH] vt-d: use two 32-bit writes to update DMAR fault address registers

> From: Roger Pau Monné [mailto:roger@citrix.com] > Sent: Monday, September 18, 2017 5:10 PM > > On Mon, Sep 18, 2017 at 05:05:18PM +0800, Haozhong Zhang wrote: > > On 09/18/17 02:30 -0600, Jan Beulich wrote: > > > >>> On 18.09.17 at 10:18, wrote: > > > >> From: Jan

Re: [Xen-devel] [PATCH v11 5/5] x86emul: Raise #UD when emulating an unimplemented instruction.

> From: Petre Pircalabu [mailto:ppircal...@bitdefender.com] > Sent: Tuesday, September 12, 2017 10:32 PM > > Modified the behavior of hvm_emulate_one_insn and > vmx_realmode_emulate_one to generate an Invalid Opcode trap when > X86EMUL_UNIMPLEMENTED is returned by the emulator instead of just >

Re: [Xen-devel] [PATCH v11 3/5] x86emul: Add return code information to error messages

> From: Petre Pircalabu [mailto:ppircal...@bitdefender.com] > Sent: Tuesday, September 12, 2017 10:32 PM > > - print the return code of the last failed emulator operation > in hvm_dump_emulation_state. > - print the return code in sh_page_fault (SHADOW_PRINTK) to make the > distiction between

Re: [Xen-devel] [PATCH v2 2/4] x86/hvm: Rename enum hvm_copy_result to hvm_translation_result

> From: Alexandru Isaila [mailto:aisa...@bitdefender.com] > Sent: Saturday, September 9, 2017 12:06 AM > > From: Andrew Cooper > > Signed-off-by: Andrew Cooper Reviewed-by: Kevin Tian

Re: [Xen-devel] [PATCH] vt-d: use two 32-bit writes to update DMAR fault address registers

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, September 11, 2017 6:03 PM > > >>> On 11.09.17 at 08:00, wrote: > > The 64-bit DMAR fault address is composed of two 32 bits registers > > DMAR_FEADDR_REG and DMAR_FEUADDR_REG. According to VT-d spec: > >

Re: [Xen-devel] [PATCH] vt-d: use two 32-bit writes to update DMAR fault address registers

> From: Zhang, Haozhong > Sent: Monday, September 11, 2017 8:13 PM > > On 09/11/17 10:38 +0100, Roger Pau Monné wrote: > > On Mon, Sep 11, 2017 at 02:00:48PM +0800, Haozhong Zhang wrote: > > > The 64-bit DMAR fault address is composed of two 32 bits registers > > > DMAR_FEADDR_REG and

Re: [Xen-devel] [PATCH 3/3] x86/cpuidle: add new CPU families

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, September 11, 2017 6:04 PM > To: xen-devel <xen-de...@lists.xenproject.org> > Cc: Andrew Cooper <andrew.coop...@citrix.com>; Nakajima, Jun > <jun.nakaj...@intel.com>; Tian, Kevin <kevin.t...@i

Re: [Xen-devel] [PATCH 2/3] VMX: add new CPU families to LBR handling

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, September 11, 2017 6:04 PM > > Bring code up-to-date with SDM version 063, including the LBR format > enumeration. > > Signed-off-by: Jan Beulich Acked-by: Kevin Tian

Re: [Xen-devel] [PATCH 1/3] VMX: convert CPU family numbers to hex

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, September 11, 2017 6:03 PM > > This makes it easier to match them against SDM updates. Also update a > few comments with names as per SDM version 063. > > Signed-off-by: Jan Beulich Acked-by: Kevin Tian

Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0

> 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: > > >>> On 25.08.17 at 14:15, wrote: > > > On Wed, Aug 23, 2017 at 02:16:38AM -0600, Jan Beulich wrote: > > >> >>>

Re: [Xen-devel] [PATCH v2 3/4] x86/vtd: introduce a PVH implementation of iommu_inclusive_mapping

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, August 23, 2017 4:19 PM > To: Roger Pau Monne <roger@citrix.com> > Cc: Tian, Kevin <kevin.t...@intel.com>; xen-de...@lists.xenproject.org > Subject: Re: [Xen-devel] [PATCH v2 3/4] x86/vtd: intro

Re: [Xen-devel] [PATCH v2 3/4] x86/vtd: introduce a PVH implementation of iommu_inclusive_mapping

> From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: Thursday, August 17, 2017 5:39 PM > > > > > > > +void __hwdom_init vtd_set_pvh_hwdom_mapping(struct domain *d) > > > +{ > > > +unsigned long pfn; > > > + > > > +BUG_ON(!is_hardware_domain(d)); > > > + > > > +if (

Re: [Xen-devel] [PATCH v2 2/4] x86/dom0: prevent PVH Dom0 from mapping read-only the IO APIC area

> From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: Thursday, August 17, 2017 5:35 PM > > On Thu, Aug 17, 2017 at 03:12:45AM +, Tian, Kevin wrote: > > > From: Roger Pau Monne > > > Sent: Saturday, August 12, 2017 12:43 AM > > > > > >

Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0

> From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: Thursday, August 17, 2017 5:32 PM > > On Thu, Aug 17, 2017 at 03:12:02AM +, Tian, Kevin wrote: > > > From: Roger Pau Monne > > > Sent: Saturday, August 12, 2017 12:43 AM > > > >

Re: [Xen-devel] [PATCH v10] VT-d: use correct BDF for VF to search VT-d unit

> From: Gao, Chao > Sent: Monday, August 28, 2017 10:42 AM > > When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' > are under the scope of the same VT-d unit as the 'Physical Function'. > A 'Physical Function' can be a 'Traditional Function' or an ARI > 'Extended Function'. And

Re: [Xen-devel] [PATCH RESEND v9] VT-d: use correct BDF for VF to search VT-d unit

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, August 25, 2017 11:20 PM > > > > Currently, VF won't implement SRIOV feature, seeing > > SRIOV specv1.1 chapter 3.7 PCI Express Extended Capabilities. Even VF > > will implement SRIOV later, I think as long as a function is SRIOV >

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

> From: Lan, Tianyu > Sent: Friday, August 18, 2017 8:22 AM > > This patch is to introduct an abstract layer for arch vIOMMU > implementation > to deal with requests from dom0. Arch vIOMMU code needs to provide > callback > to perform create, destroy and query capabilities operation. > >

Re: [Xen-devel] [PATCH v7] VT-d: use correct BDF for VF to search VT-d unit

> 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 'Physical Function' are > > under > > the scope of the same VT-d

Re: [Xen-devel] [PATCH v7] VT-d: use correct BDF for VF to search VT-d unit

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, August 23, 2017 4:53 PM > > >>> On 23.08.17 at 09:42, wrote: > > 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

Re: [Xen-devel] [PATCH v7] VT-d: use correct BDF for VF to search VT-d unit

> From: Gao, Chao > Sent: Tuesday, August 22, 2017 5:52 AM > > When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are > under > the scope of the same VT-d unit as the 'Physical Function'. A 'Physical > Function' can be a 'Traditional Function' or an ARI 'Extended Function'. >

Re: [Xen-devel] [PATCH v4 37/53] xen/drivers/passthrough/vtd/quirks.c: let custom parameter parsing routines return errno

> From: Juergen Gross [mailto:jgr...@suse.com] > Sent: Thursday, August 24, 2017 1:35 AM > > Modify the custom parameter parsing routines in: > > xen/drivers/passthrough/vtd/quirks.c > > to indicate whether the parameter value was parsed successfully. > > Cc: Kevin Tian

Re: [Xen-devel] [PATCH v4 36/53] xen/drivers/passthrough/vtd/dmar.c: let custom parameter parsing routines return errno

> From: Juergen Gross [mailto:jgr...@suse.com] > Sent: Thursday, August 24, 2017 1:34 AM > > Modify the custom parameter parsing routines in: > > xen/drivers/passthrough/vtd/dmar.c > > to indicate whether the parameter value was parsed successfully. > > Cc: Kevin Tian >

Re: [Xen-devel] [PATCH v4 11/53] xen/arch/x86/hvm/vmx/vmcs.c: let custom parameter parsing routines return errno

> From: Juergen Gross [mailto:jgr...@suse.com] > Sent: Thursday, August 24, 2017 1:34 AM > > Modify the custom parameter parsing routines in: > > xen/arch/x86/hvm/vmx/vmcs.c > > to indicate whether the parameter value was parsed successfully. > > Cc: Jun Nakajima > Cc:

Re: [Xen-devel] [PATCH v4 01/53] xen: add an optional string end parameter to parse_bool()

> From: Juergen Gross [mailto:jgr...@suse.com] > Sent: Thursday, August 24, 2017 1:34 AM > > Add a parameter to parse_bool() to specify the end of the to be > parsed string. Specifying it as NULL will preserve the current > behavior to parse until the end of the input string, while passing > a

Re: [Xen-devel] [PATCH v4] hvm: vmx/svm_cpu_up_prepare should be called only once

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Tuesday, August 22, 2017 10:08 AM > > These routines are first called via CPU_UP_PREPARE notifier by > the BSP and then by the booting ASP from vmx_cpu_up()/_svm_cpu_up(). > > Avoid the unnecessary second call. Because BSP

Re: [Xen-devel] [PATCH v6] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

> From: Gao, Chao > Sent: Wednesday, August 16, 2017 1:12 PM > > 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 PF is an extended function, the BDF of a traditional function > within the same device should be

Re: [Xen-devel] [PATCH v2 3/4] x86/vtd: introduce a PVH implementation of iommu_inclusive_mapping

> From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: Saturday, August 12, 2017 12:43 AM > > On certain Intel systems, as far as I can tell almost all pre-Haswell ones, > trying to boot a PVH Dom0 will freeze the box completely, up to the point > that > not even the watchdog works. The

Re: [Xen-devel] [PATCH v2 2/4] x86/dom0: prevent PVH Dom0 from mapping read-only the IO APIC area

> From: Roger Pau Monne > Sent: Saturday, August 12, 2017 12:43 AM > > This is emulated by Xen and must not be mapped into PVH Dom0 p2m. same comment as previous one. please send it separately. > > Signed-off-by: Roger Pau Monné > --- > Cc: Jan Beulich

Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0

> From: Roger Pau Monne > Sent: Saturday, August 12, 2017 12:43 AM > > They are emulated by Xen, so they must not be mapped into Dom0 p2m. > Introduce a helper function to add the MMCFG areas to the list of > denied iomem regions for PVH Dom0. > > Signed-off-by: Roger Pau Monné

Re: [Xen-devel] [PATCH v2 0/4] x86/pvh: implement iommu_inclusive_mapping for PVH Dom0

> From: Roger Pau Monne > Sent: Saturday, August 12, 2017 12:43 AM > > Hello, > > Currently iommu_inclusive_mapping is not working for PVH Dom0, this not working for all platforms or only older boxes? The subject indicates the former while the later description seems the latter... > patch >

Re: [Xen-devel] [PATCH v3 2/3] x86/p2m: make p2m_alloc_ptp() return an MFN

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, August 11, 2017 9:20 PM > > None of the callers really needs the struct page_info pointer. > > Signed-off-by: Jan Beulich > Acked-by: George Dunlap Reviewed-by: Kevin Tian

Re: [Xen-devel] [PATCH v4] VT-d PI: disable VT-d PI when CPU-side PI isn't enabled

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, August 3, 2017 5:44 PM > > >>> On 13.06.17 at 10:29, wrote: > On 13.06.17 at 10:20, wrote: > >> From the context calling pi_desc_init(), we can conclude the current > >> implementation

Re: [Xen-devel] [PATCH v2 00/13] "Non-shared" IOMMU support on ARM

> From: Oleksandr Tyshchenko [mailto:olekst...@gmail.com] > Sent: Tuesday, August 1, 2017 7:08 PM > > Hi, Kevin > > On Tue, Aug 1, 2017 at 6:06 AM, Tian, Kevin <kevin.t...@intel.com> wrote: > >> From: Oleksandr Tyshchenko [mailto:olekst...@gmail.com] > &g

Re: [Xen-devel] Xen on Intel Atom E3815: crash, no output

> From: Stefano Stabellini [mailto:sstabell...@kernel.org] > Sent: Tuesday, August 1, 2017 7:40 AM > > Hi all, > > I noticed that Xen does not boot on Intel Atom E3815. The system is a > Dell Edge Gateway 3003: > > http://i.dell.com/sites/doccontent/shared-content/data- >

Re: [Xen-devel] [PATCH v2 00/13] "Non-shared" IOMMU support on ARM

> From: Oleksandr Tyshchenko [mailto:olekst...@gmail.com] > Sent: Monday, July 31, 2017 7:58 PM > > Hi, Kevin > > On Mon, Jul 31, 2017 at 8:57 AM, Tian, Kevin <kevin.t...@intel.com> wrote: > >> From: Oleksandr Tyshchenko > >> Sent: Wednesday, July

Re: [Xen-devel] [PATCH v2] VT-d: don't panic/warn on iommu=no-igfx

> From: Rusty Bird [mailto:rustyb...@openmailbox.org] > Sent: Monday, July 31, 2017 5:04 PM > > When operating on an Intel graphics device, iommu_enable_translation() > panicked (force_iommu==1) or warned (force_iommu==0) about the BIOS if > is_igd_vt_enabled_quirk() returned 0. That's good if

Re: [Xen-devel] [PATCH] VT-d: don't panic/warn on iommu=no-igfx

> From: Rusty Bird [mailto:rustyb...@openmailbox.org] > Sent: Thursday, July 27, 2017 7:54 PM > > When operating on an Intel graphics device, iommu_enable_translation() > panicked (force_iommu==1) or warned (force_iommu==0) about the BIOS if > is_igd_vt_enabled_quirk() returned 0. That's good if

Re: [Xen-devel] [PATCH v2 00/13] "Non-shared" IOMMU support on ARM

> From: Oleksandr Tyshchenko > Sent: Wednesday, July 26, 2017 1:27 AM > > From: Oleksandr Tyshchenko > > Hi, all. > > The purpose of this patch series is to create a base for porting > any "Non-shared" IOMMUs to Xen on ARM. Saying "Non-shared" IOMMU I > mean >

Re: [Xen-devel] [PATCH 3/6] x86/vmx: Introduce and use struct vmx_msr_bitmap

> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of > Andrew Cooper > > On 27/07/2017 07:02, Tian, Kevin wrote: > >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > >> Sent: Wednesday, July 19, 2017 7:58 PM > >> > >> Thi

Re: [Xen-devel] [PATCH v2 3/5] x86/vmx: refactor vmx_init_vmcs_config()

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, July 24, 2017 9:48 PM > > 1. Remove RDMSRs of VMX MSRs since all values are already available in >raw_vmx_msr_policy. > 2. Replace bit operations involving VMX bitmasks with accessing VMX >features by name and using

Re: [Xen-devel] [PATCH v2 2/5] x86/vmx: add raw_vmx_msr_policy

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, July 24, 2017 9:48 PM > > Add calculate_vmx_raw_policy() which fills the raw_vmx_msr_policy > object (the actual contents of H/W VMX MSRs) on the boot CPU. On > secondary CPUs, this function checks that contents of VMX MSRs

Re: [Xen-devel] [PATCH v2 1/5] x86/vmx: add struct vmx_msr_policy

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, July 24, 2017 9:48 PM > > This structure provides a convenient way of accessing contents of > VMX MSRs: every bit value is accessible by its name. Bit names match > existing Xen's definitions as close as possible. The

Re: [Xen-devel] [PATCH v2 0/5] VMX MSRs policy for Nested Virt: part 1

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, July 24, 2017 9:48 PM > > The end goal of having VMX MSRs policy is to be able to manage > L1 VMX features. This patch series is the first part of this work. > There is no functional change to what L1 sees in VMX MSRs at this

Re: [Xen-devel] [PATCH 6/6] x86/vvmx: Fix auditing of MSR_BITMAP parameter

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, July 19, 2017 7:58 PM > > The MSR_BITMAP field is required to be page aligned. Also switch gpa to be > a > uint64_t, as the MSR_BITMAP is strictly a 64bit VMCS field. > > Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH 5/6] x86/vvmx: Fix handing of the MSR_BITMAP field with VMCS shadowing

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, July 19, 2017 7:58 PM > > Currently, the following sequence of actions: > > * VMPTRLD (creates a mapping, likely pointing at gfn 0 for an empty vmcs) > * VMWRITE CPU_BASED_VM_EXEC_CONTROL (completed by hardware) > *

Re: [Xen-devel] [PATCH 4/6] x86/vvmx: Switch nested MSR intercept handling to use struct vmx_msr_bitmap

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, July 19, 2017 7:58 PM > > Rename vmx_check_msr_bitmap() to vmx_msr_is_intercepted() in order to > more > clearly identify what the boolean return value means. Change the int > access_type to bool is_write. > > The NULL

Re: [Xen-devel] [PATCH 3/6] x86/vmx: Introduce and use struct vmx_msr_bitmap

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, July 19, 2017 7:58 PM > > This avoids opencoding the bitmap bases in accessor functions. Introduce a > build_assertions() function to check the structure layout against the manual > definiton. In addition, drop some

Re: [Xen-devel] [PATCH 2/6] x86/vpmu: Use vmx_{clear, set}_msr_intercept() rather than opencoding them

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, July 19, 2017 8:18 PM > > On 19/07/17 12:57, Andrew Cooper wrote: > > No functional change. > > > > Signed-off-by: Andrew Cooper > > I have just realise I can now drop msraddr_to_bitpos(), so

Re: [Xen-devel] [PATCH 1/6] x86/vmx: Improvements to vmx_{dis, en}able_intercept_for_msr()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, July 19, 2017 7:58 PM > > * Shorten the names to vmx_{clear,set}_msr_intercept() > * Use an enumeration for MSR_TYPE rather than a plain integer > * Introduce VMX_MSR_RW, as most callers alter both the read and write >

Re: [Xen-devel] [PATCH v5] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

> From: Gao, Chao > Sent: Thursday, July 6, 2017 3:58 PM > > 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 PF is an extended function, the BDF of a traditional function within the > same device should be used

Re: [Xen-devel] [PATCH v4] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

> From: Gao, Chao > Sent: Wednesday, July 5, 2017 3:57 PM > > On Wed, Jul 05, 2017 at 01:18:38PM +0800, Tian, Kevin wrote: > >> From: Gao, Chao > >> Sent: Wednesday, July 5, 2017 12:28 PM > >> > >> On Wed, Jul 05, 2017 at 10:46:39AM +0800, Tian, K

Re: [Xen-devel] [PATCH v4] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

> From: Gao, Chao > Sent: Wednesday, July 5, 2017 12:28 PM > > On Wed, Jul 05, 2017 at 10:46:39AM +0800, Tian, Kevin wrote: > >> From: Gao, Chao > >> Sent: Monday, July 3, 2017 12:37 PM > >> > >> On Fri, Jun 30, 2017 at 05:19:52PM +0800, Tian, K

Re: [Xen-devel] [PATCH v1 3/6] vmx: refactor vmx_init_vmcs_config()

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, June 26, 2017 6:45 PM > > 1. Remove RDMSRs of VMX MSRs since all values are already available in >raw_vmx_msr_policy. > 2. Replace bit operations involving VMX bitmasks with accessing VMX >features by name and using

Re: [Xen-devel] [PATCH v1 1/6] vmx: add struct vmx_msr_policy

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, June 26, 2017 6:45 PM > > This structure provides a convenient way of accessing contents of > VMX MSRs: every bit value is accessible by its name. Bit names match > existing Xen's definitions as close as possible. > > The

Re: [Xen-devel] [PATCH v1 0/6] VMX MSRs policy for Nested Virt: part 1

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, June 26, 2017 6:44 PM > > The end goal of having VMX MSRs policy is to be able to manage > L1 VMX features. This patch series is the first part of this work. > There is no functional change to what L1 sees in VMX MSRs at this

Re: [Xen-devel] [PATCH v4] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

> From: Gao, Chao > Sent: Monday, July 3, 2017 12:37 PM > > On Fri, Jun 30, 2017 at 05:19:52PM +0800, Tian, Kevin wrote: > >> From: Gao, Chao > >> Sent: Friday, June 30, 2017 9:17 AM > >> > >> The problem is for a VF of RC integrated PF (e.g. PF

Re: [Xen-devel] [PATCH v1] vvmx: fix ept_sync() for nested p2m

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Wednesday, June 28, 2017 5:36 PM > > If ept_sync_domain() is called for np2m, the following happens: > > 1. *np2m*::ept_data::invalidate cpumask is updated > 2. IPIs are sent for CPUs in domain_dirty_cpumask forcing vmexits

Re: [Xen-devel] [PATCH] x86/vvmx: Fix WRMSR interception of VMX MSRs

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, June 28, 2017 10:16 PM > > FEATURE_CONTROL is already read with LOCK bit set (so is unmodifiable), > and > all VMX MSRs are read-only. Also, fix the > MSR_IA32_VMX_TRUE_ENTRY_CTLS bound > to be MSR_IA32_VMX_VMFUNC,

Re: [Xen-devel] [PATCH v4] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

> From: Gao, Chao > Sent: Friday, June 30, 2017 9:17 AM > > 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. > > From SRIOV spec REV 1.0 section 3.7.3, it says: > "ARI is not applicable to Root Complex integrated

Re: [Xen-devel] [PATCH 1/2] Revert "x86/hvm: disable pkeys for guests in non-paging mode"

> From: Han, Huaitong > Sent: Wednesday, May 31, 2017 4:15 PM > > On Wed, 2017-05-31 at 08:44 +0100, Andrew Cooper wrote: > > On 31/05/2017 08:09, Han, Huaitong wrote: > > > On Fri, 2017-05-26 at 18:03 +0100, Andrew Cooper wrote: > > >> This reverts commit

Re: [Xen-devel] [PATCH v2] x86/vmx: Fix vmentry failure because of invalid LER on Broadwell

> From: Ross Lagerwall [mailto:ross.lagerw...@citrix.com] > Sent: Tuesday, May 30, 2017 10:05 PM > > Occasionally, on certain Broadwell CPUs MSR_IA32_LASTINTTOIP has been > observed to have the top three bits corrupted as though the MSR is using > the LBR_FORMAT_EIP_FLAGS_TSX format. This is

Re: [Xen-devel] [PATCH v2 3/5] VT-d PI: restrict the vcpu number on a given pcpu

> From: Gao, Chao > Sent: Thursday, May 11, 2017 2:04 PM > > 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 > grows too long. After a simple analysis, there are 32k domains and > 128 vcpu per domain,

Re: [Xen-devel] [PATCH v2 1/5] xentrace: add TRC_HVM_PI_LIST_ADD

> From: Gao, Chao > Sent: Thursday, May 11, 2017 2:04 PM > > 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 > --- >

Re: [Xen-devel] [PATCH v2 for-4.9] x86/mm: Fix incorrect unmapping of 2MB and 1GB pages

> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com] > Sent: Wednesday, May 10, 2017 7:13 PM > > The same set of functions is used to set as well as to clean > P2M entries, except that for clean operations INVALID_MFN (~0UL) > is passed as a parameter. Unfortunately, when calculating an >

Re: [Xen-devel] [PATCH v3] x86/vpmu_intel: Fix hypervisor crash by masking PC bit in MSR_P6_EVNTSEL

> From: Jan Beulich > Sent: Friday, May 5, 2017 6:16 PM > > >>> On 04.05.17 at 23:30, wrote: > > Setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results in a General > > Protection Fault and thus results in a hypervisor crash. This behavior has > > been observed on

Re: [Xen-devel] [PATCH] VMX: constrain vmx_intr_assist() debugging code to debug builds

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, May 4, 2017 8:02 PM > > This is because that code, added by commit 997382b771 ("y86/vmx: dump > PIR and vIRR before ASSERT()"), was meant to be removed by the time we > finalize 4.9, but the root cause of the ASSERT() wrongly(?)

Re: [Xen-devel] [PATCH v2] x86/vpmu_intel: Fix hypervisor crash by masking PC bit in MSR_P6_EVNTSEL

> From: Tian, Kevin > Sent: Friday, April 28, 2017 2:43 PM > > > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > > Sent: Thursday, April 27, 2017 11:18 PM > > > > On 04/27/2017 11:05 AM, Jan Beulich wrote: > > >>>> On 27.04.17 at 16:5

Re: [Xen-devel] [PATCH v2] x86/vpmu_intel: Fix hypervisor crash by masking PC bit in MSR_P6_EVNTSEL

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Thursday, April 27, 2017 11:18 PM > > On 04/27/2017 11:05 AM, Jan Beulich wrote: > On 27.04.17 at 16:57, wrote: > >> On 04/27/2017 03:32 AM, Jan Beulich wrote: > >> On 26.04.17 at 20:50,

Re: [Xen-devel] [PATCH for-4.9 v2] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

> From: Gao, Chao > Sent: Thursday, April 27, 2017 10:47 AM > > 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 > corresponding bit in vIRR, the

Re: [Xen-devel] [RFC PATCH] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

> From: Gao, Chao > Sent: Friday, April 21, 2017 12:23 PM > > >> @@ -487,13 +494,14 @@ int vpic_ack_pending_irq(struct vcpu *v) > >> struct hvm_hw_vpic *vpic = >domain->arch.hvm_domain.vpic[0]; > >> > >> ASSERT(has_vpic(v->domain)); > >> +ASSERT(vpic_is_locked(vpic)); > >> > >>

Re: [Xen-devel] [RFC PATCH] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

> 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 inconsistent operation is operated -> operations are done > views of vIOAPIC. For example, if a

Re: [Xen-devel] [PATCH] x86/hvm: Corrections and improvements to unhandled vmexit logging

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, April 19, 2017 11:58 PM > > * Use gprintk rather than gdprintk. These logging messages shouldn't >disappear in release builds, as they usually happen immediately before a >domain crash. Raise them from WARNING

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

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

  1   2   3   4   5   6   7   8   9   >