> 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 calculat
> 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 VMCS
> 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 0x820
> 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 __pag
> 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 11:02:09P
> 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 https://lists.xenp
> 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
___
Xen-de
> 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:2
> 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
> >> timeout occurs because
> 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.
>
> Signed
> 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 VT-d
> 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
__
> 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 usage
> 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
Acked-by: Kevin Tian
> 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 Pircalabu wrote:
> Enfor
> 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.
> >
> > Signed-off-by: Andrew Cooper
>
> 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 Tian
___
> 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 __page_to_
> 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
>
> I
> 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
>
> I
> 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
Reviewed-by: Kevin T
> 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 usabl
> 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 1
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 P
> 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
> 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: Tamas K Lengyel
> Cc: George Dunlap
> Cc: Jun Nakajima
> Cc: Kevin Tian
Reviewed-by: Kevin T
> 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 "d
> 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 Beulich [mailto:jbeul...@
> 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
> cr
> 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 X86E
> 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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists
> 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:
> > "Software is expected to acce
> 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 DMAR_FEUADDR
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 11, 2017 6:04 PM
> To: xen-devel
> Cc: Andrew Cooper ; Nakajima, Jun
> ; Tian, Kevin
> Subject: [PATCH 3/3] x86/cpuidle: add new CPU families
>
> Bring code up-to-date with SDM version 063.
>
&
> 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
___
Xen-devel maili
> 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
___
> 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:
> > >> >>> On 22.08.17 at 15:54,
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, August 23, 2017 4:19 PM
> To: Roger Pau Monne
> Cc: Tian, Kevin ; xen-de...@lists.xenproject.org
> Subject: 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 ( !iommu_incl
> 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
> > >
> > >
> 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
> > >
> > &g
> 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 f
> 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
> >
> 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.
>
> Signed-o
> 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 sc
> 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 23, 2017 at 08:31:51A
> 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'.
> And
> 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
> Signed-off-by: Juerge
> 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
> Signed-off-by: Juergen
> 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: Kevin Tian
> Cc: Jan Be
> 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 non
> 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 doesn'
> 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 us
> 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 fre
> 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
> Cc: Andrew Cooper
> ---
> xen/arch/x
> 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é
this patch is a
> 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
> ser
> 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
___
Xen-devel
> 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 of VT-d PI depends on CPU-side PI. If we
> 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 wrote:
> >> From: Oleksandr Tyshchenko [mailto:olekst...@gmail.com]
> >> Sent: Monday, July
> 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-
> sheets/en/Documents/Del
> 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 wrote:
> >> From: Oleksandr Tyshchenko
> >> Sent: Wednesday, July 26, 2017 1:27 AM
> >>
> 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 the
> 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 t
> 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
> the IOMMU that can't share the pag
> 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
> 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 vm
> 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 ma
> 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 structur
> 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
> 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
Acked-by: Kevin Ti
> 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)
> * VM
> 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 p
> 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 stal
> 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 have folded
> the additional
> 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
>
> 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 t
> 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
> 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
> 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 vm
> 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 st
> 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
> 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
> 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
>
> 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, rather
> 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 Endpoints
> 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 c41e0266dd59ab50b7a153157e9bd2a3ad114b53.
> 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 incor
> 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, thu
> 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
> ---
> tools/xentrace/formats
> 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
> app
> 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 two generations of Intel pr
> 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(?) trig
> 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 a
> 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, wrote:
> On 04/26/2017 02:1
> 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 correspo
> 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 = &v->domain->arch.hvm_domain.vpic[0];
> >>
> >> ASSERT(has_vpic(v->domain));
> >> +ASSERT(vpic_is_locked(vpic));
> >>
> >>
> 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
> 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 t
> 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
___
Xen-devel mailing list
X
1 - 100 of 920 matches
Mail list logo