> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Thursday, December 13, 2018 4:40 PM
>
> On Thu, Dec 13, 2018 at 02:44:00AM +, Tian, Kevin wrote:
> > btw can you also capture ISR/IRR/PPR right before local_irq_enable()?
> > though I didn't see a r
> From: Tian, Kevin
> Sent: Tuesday, December 11, 2018 3:10 PM
>
> > From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> > Sent: Tuesday, December 11, 2018 1:13 AM
> >
> > Ping Kevin / Jun.
> >
> > On 16/10/2018 19:54, Andrew Cooper wrote:
>
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, December 17, 2018 10:21 PM
>
> On 17/12/2018 13:09, Andrew Cooper wrote:
> > On 17/12/2018 02:39, Tian, Kevin wrote:
> >>>>> After some investigation, it turns out that after vmentry,
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Thursday, March 22, 2018 7:33 PM
>
> New definitions provide a convenient way of accessing contents of
> VMX MSRs. They are separated into 5 logical blocks based on the
> availability conditions of MSRs in the each block:
>
> 1.
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Thursday, March 22, 2018 7:33 PM
>
> Currently, when nested virt is enabled, the set of L1 VMX features
> is fixed and calculated by nvmx_msr_read_intercept() as an intersection
> between the full set of Xen's supported L1 VMX feature
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Thursday, March 22, 2018 7:33 PM
>
> With the new cpuid infrastructure there is a domain-wide struct cpuid
> policy and there is no need to pass a separate struct vcpu * into
> hvm_cr4_guest_valid_bits() anymore. Make the function acc
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, April 10, 2018 4:44 PM
>
> >>> On 09.04.18 at 19:56, wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmcs.c
> > +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> > @@ -1788,7 +1788,10 @@ void vmcs_dump_vcpu(struct vcpu *v)
> > vmentry_ctl = vmr32(VM_EN
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Saturday, March 3, 2018 12:19 AM
>
> Commit 406817 doesn't update nested VMX code in order to take into
> account L1 CR4 host mask when nested guest (L2) writes to CR4, and
> thus the mask written to CR4_GUEST_HOST_MASK is likely not as
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, March 8, 2018 2:59 AM
>
> We currently have MSR_IA32_APICBASE and MSR_IA32_APICBASE_MSR
> which are
> synonymous from a naming point of view, but refer to very different things.
>
> Rename the x2APIC MSRs to MSR_X2APIC_*,
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 8, 2018 7:16 PM
>
> Instead of using RDMSR/WRMSR, on fsgsbase-capable systems use a
> double
> SWAPGS combined with RDGSBASE/WRGSBASE. This halves execution time
> for
> a shadow GS update alone on my Haswell (and we have indic
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 8, 2018 9:39 PM
>
> > --- a/xen/include/asm-x86/domain.h
> > +++ b/xen/include/asm-x86/domain.h
> > @@ -622,7 +622,8 @@ unsigned long pv_guest_cr4_fixup(const struct
> vcpu *, unsigned long guest_cr4);
> > X86_CR4_
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 8, 2018 9:39 PM
>
> > --- a/xen/include/asm-x86/domain.h
> > +++ b/xen/include/asm-x86/domain.h
> > @@ -622,7 +622,8 @@ unsigned long pv_guest_cr4_fixup(const struct
> vcpu *, unsigned long guest_cr4);
> > X86_CR4_
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, March 9, 2018 10:19 PM
>
> Instead of "syncing" the live value to what mmu_cr4_features has, make
> sure vCPU-s run with the value most recently loaded into %cr4, such that
> after the next VM exit we continue to run with the intended
> From: Alexey G [mailto:x19...@gmail.com]
> Sent: Tuesday, March 13, 2018 5:20 AM
>
> On Mon, 12 Mar 2018 16:32:27 -0400
> Konrad Rzeszutek Wilk wrote:
>
> >On Tue, Mar 13, 2018 at 06:10:35AM +1000, Alexey G wrote:
> >> On Mon, 12 Mar 2018 15:38:03 -0400
> >> Konrad Rzeszutek Wilk wrote:
> >>
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, March 15, 2018 8:08 PM
>
> This reduces code volume, and has a minor improvement on compiled size,
> probably due to the removal of several temporary variables.
>
> add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-50 (-50)
>
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 15, 2018 9:12 PM
>
> ... instead of directly calling handle_xsetbv(), to make use of the
> additional checking there.
>
> Also don't call hvm_monitor_crX(XCR0, ...) for indexes other than zero
> anymore.
>
> Signed-off-by: J
> From: Lars Kurth
> Sent: Thursday, March 15, 2018 2:07 AM
>
>
> ## [PATCH RFC 00/10] x86 passthrough code cleanup
>
> ## Sent in for meeting agenda by Wei
>
> https://lists.xenproject.org/archives/html/xen-devel/2018-
> 02/msg01939.html
> Wei wanted to get the maintainers opinions on what is
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, June 29, 2018 9:16 PM
>
> In shadow mode the field never changes from ~0UL, so there's no need for
> a VMWRITE (or an update of its cached value).
>
> Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
___
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Thursday, June 28, 2018 10:35 PM
>
> A VM exit handler executed immediately after enabling #VE might
> find a stale __vmsave()d EPTP_INDEX, stored by calling
> altp2m_vcpu_destroy() when
> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS
> ha
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, June 28, 2018 9:11 PM
>
> >>> On 26.06.18 at 15:18, wrote:
> > --- a/xen/include/asm-x86/msr-index.h
> > +++ b/xen/include/asm-x86/msr-index.h
> > @@ -15,6 +15,13 @@
> > * abbreviated name.
> > */
> >
> > +#define MSR_FEATURE_CO
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, June 26, 2018 2:36 PM
>
> The changes for XSA-267 did not touch management of CR0.TS for HVM
> guests. In fully eager mode this bit should never be set when
> respective vCPU-s are active, or else hvmemul_get_fpu() might leave it
> wr
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, June 26, 2018 6:34 PM
>
> On 26/06/18 07:38, Jan Beulich wrote:
> > While we don't expect CR0 to change behind our backs, cope with this
> > happening, but other than for CR4 also log a (debug) message.
> >
> > Signed-off-by
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, July 18, 2018 5:39 PM
>
> >>> On 18.07.18 at 11:36, wrote:
> > On Mon, Jul 16, 2018 at 10:46:11AM -0600, Jan Beulich wrote:
> >> For a reason that I can't explain, it is only the shim build that fails
> >> for me with an older gcc
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, July 11, 2018 9:23 PM
>
> Three of the four hooks are not exposed outside of vmx.c, and all of
> them have only a single possible non-NULL value. So there's no reason to
> use hooks here - a simple set of flag indicators is sufficie
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, July 11, 2018 9:24 PM
>
> Instead of checking hvm_tsc_scaling_supported inside the hook function,
> install the hook only when setting state such that said predicate
> becomes true.
>
> Signed-off-by: Jan Beulich
Acked-by: Kevin
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, July 11, 2018 9:25 PM
>
> From: Suravee Suthikulpanit
>
> This patch modifies the hvm_funcs.virtual_intr_delivery_enabled()
> to become a bool variable as VMX does and SVM will simply return a
> static value.
>
> Signed-off-by: S
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, July 11, 2018 9:26 PM
>
> Commit a1b1572833 ("VMX: add VMFUNC leaf 0 (EPTP switching) to
> emulator") needlessly introduced it, and no user has appeared since.
>
> Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
___
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, July 11, 2018 9:44 PM
>
> While not strictly necessary, change the VMX initialization logic to
> update the function table in start_vmx() from NULL rather than to NULL,
> to make more obvious that we won't ever change an already (ex
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, July 17, 2018 5:28 PM
>
> On 04/06/18 14:59, Andrew Cooper wrote:
> > c/s 4f36452b63 introduced a write to %dr6 in the #DB intercept case, but
> the
> > guests debug registers may be lazy at this point, at which point the gu
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, July 19, 2018 2:16 PM
>
> >>> On 19.07.18 at 03:56, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Wednesday, July 11, 2018 9:25 PM
> >>
> >> From: Suravee Suthikulpanit
> >>
> >> This patch modifies the hvm_f
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Wednesday, August 1, 2018 5:02 PM
>
> On 07/23/2018 01:29 PM, George Dunlap wrote:
> > On 07/20/2018 07:02 PM, Razvan Cojocaru wrote:
> >> On 07/20/2018 08:18 PM, George Dunlap wrote:
> >>> Furthermore, imagine the following scenar
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Thursday, August 2, 2018 2:26 PM
>
> vmx_vmexit_handler() assumes that if
> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set, that the value in
> EPTP_INDEX is valid. Unfortunately, the function which sets this bit
> (vmx_vcpu_update_
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Wednesday, August 1, 2018 4:34 PM
>
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On
> Behalf
> > Of Jan Beulich
> > Sent: 01 August 2018 09:21
> > To: Roger Pau Monne
> > Cc: Kevin
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, August 1, 2018 8:08 PM
>
> If the EPTP pointer can't be located in the altp2m list, the domain
> is (legitimately) crashed.
>
> Under those circumstances, execution will continue and guarentee to hit
> the
> BUG_ON(idx >=
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, August 1, 2018 8:55 PM
>
> There is no need for the syncrhonous varient, as the vmentry failure path
> can
> just return to processing softirqs.
>
> This is in aid of trying to remove domain_crash_syncrhonous() from the
>
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Wednesday, August 1, 2018 7:04 PM
>
> Remove the handling for different page sizes now that ia64 is gone.
>
> No functional change.
>
> Reported by: Jan Beulich
> Signed-off-by: Roger Pau Monné
Acked-by: Kevin Tian
___
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Wednesday, August 1, 2018 7:04 PM
>
> To select the iommu configuration used by Dom0. This option supersedes
> iommu=dom0-strict|dom0-passthrough.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
> ---
> Changes since v1:
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Wednesday, August 1, 2018 7:04 PM
>
> Introduce a new dom0-iommu=inclusive generic option that supersedes
> iommu_inclusive_mapping. The prevcious behaviour is preserved and the
> option should only be enabled by default on Intel hardwa
> From: Roger Pau Monne
> Sent: Wednesday, August 1, 2018 7:04 PM
>
> Several people have reported hardware issues (malfunctioning USB
> controllers) due to iommu page faults on Intel hardware. Those faults
> are caused by missing RMRR (VTd) entries in the ACPI tables. Those can
> be worked around
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Friday, August 3, 2018 5:33 PM
>
> On Fri, Aug 03, 2018 at 10:14:49AM +0100, Paul Durrant wrote:
> > > -Original Message-
> > > From: Roger Pau Monne
> > > Sent: 03 August 2018 10:09
> > > To: Paul Durrant
> > > Cc: Jan Beulich
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 4, 2018 1:22 AM
>
> ...meaning 'bus frame number' i.e. a frame number mapped in the IOMMU
> rather than the MMU.
>
> This patch is a largely cosmetic change that substitutes the terms 'gfn'
> and 'gaddr' for 'bfn' and
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 4, 2018 1:22 AM
>
> This patch modifies the declaration of the entry points to the IOMMU
> sub-system to use bfn_t and mfn_t in place of unsigned long. A subsequent
> patch will similarly modify the methods in the iommu
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 4, 2018 1:22 AM
>
> This patch modifies the methods in struct iommu_ops to use type-safe BFN
> and MFN. This follows on from the prior patch that modified the functions
> exported in xen/iommu.h.
>
> Signed-off-by: Pau
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 4, 2018 1:22 AM
>
> Turn iommu_map/unmap_page() into straightforward wrappers that check
> the
iommu_iotlb_flush is also changed.
> existence of the relevant iommu_op and call through to it. This makes them
> usable b
> From: Paul Durrant
> Sent: Saturday, August 4, 2018 1:22 AM
>
> This patch introduces the boilerplate for a new hypercall to allow a
> domain to control IOMMU mappings for its own pages.
> Whilst there is duplication of code between the native and compat entry
> points which appears ripe for som
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 4, 2018 1:22 AM
>
> Ranges that should be considered reserved in the IOMMU are not
> necessarily
> limited to RMRRs. If iommu_inclusive_mapping is set then any frame
> number
> falling within an E820 reserved region sho
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 4, 2018 1:22 AM
>
> This patch adds a new method to the VT-d IOMMU implementation to find
> the
> MFN currently mapped by the specified BFN along with a wrapper function
> in
> generic IOMMU code to call the implementat
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 4, 2018 1:22 AM
>
> The name 'iommu_use_hap_pt' suggests that that P2M table is in use as
> the
> domain's IOMMU pagetable which, prior to this patch, is not strictly true
> since the macro did not test whether the doma
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 4, 2018 1:22 AM
>
> The name 'need_iommu' is a little confusing as it suggests a domain needs
> to use the IOMMU but something might not be set up yet, when in fact it
> doesn't become true until IOMMU mappings for the
> From: Paul Durrant
> Sent: Saturday, August 4, 2018 1:22 AM
>
> This patch adds an iommu_op which checks whether it is possible or
> safe for a domain to modify its own IOMMU mappings and, if so, creates
> a rangeset to track modifications.
Have to say that there might be a concept mismatch bet
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, August 7, 2018 4:16 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 07 August 2018 04:04
> > To: Paul Durrant ; xen-
> de...@list
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, August 7, 2018 4:00 PM
>
> > > *
> > > * gfn: Guest Frame Number
> > > * The values a guest puts in its own pagetables. For an auto-
> translated
> > > @@ -26,6 +27,11 @@
> > > * A linear idea of a guest physical a
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, August 7, 2018 4:22 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 07 August 2018 04:25
> > To: Paul Durrant ; xen-
> de...@lists.xenproj
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, August 7, 2018 4:30 PM
>
> >>> On 07.08.18 at 10:21, wrote:
> >> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> >> Sent: 07 August 2018 04:25
> >>
> >> > From: Paul Du
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, August 7, 2018 4:33 PM
>
> >
> > > From: Paul Durrant
> > > Sent: Saturday, August 4, 2018 1:22 AM
> > >
> > > This patch adds an iommu_op which checks whether it is possible or
> > > safe for a domain to modify its own IOMMU m
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, August 7, 2018 4:36 PM
>
> > > > > +static int intel_iommu_lookup_page(struct domain *d, bfn_t bfn,
> > > mfn_t
> > > > > *mfn,
> > > > > + unsigned int *flags)
> > > >
> > > > Not looking at l
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, August 7, 2018 4:37 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 07 August 2018 09:33
> > To: Jan Beulich ; Paul Durrant
> >
> From: Paul Durrant
> Sent: Tuesday, August 7, 2018 4:44 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 07 August 2018 09:38
> > To: Paul Durrant ; xen-
> de...@lists.xenproject.org
> > Cc: Stefan
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, August 7, 2018 4:56 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 07 August 2018 09:48
> > To: Paul Durrant ; Jan Beulich
> >
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, August 7, 2018 5:12 PM
>
>
> > So here current version pvIOMMU only provides global address space,
> > though unlike any existing IOMMU. maybe we should explicitly call out
> > this fact in some capability field for future ext
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, May 22, 2018 7:21 PM
>
> Collect together related infrastructure in vmcs.h, rather than having it
> spread out. Turn vmx_{read,write}_guest_msr() into static inlines, as they
> are simple enough.
>
> Replace 'int type' wit
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, May 22, 2018 7:21 PM
>
> * Use an arch_vmx_struct local variable to reduce later code volume.
> * Use start/total instead of msr_area/msr_count. This is in preparation for
>more finegrained handling with later changes
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, May 22, 2018 7:21 PM
>
> Instead of having multiple algorithms searching the MSR lists, implement a
> single one. It has the semantics required by vmx_add_msr(), to identify the
> position in which an MSR should live, if it
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, May 22, 2018 7:21 PM
>
> At the moment, all modifications of the MSR lists are in current context.
> However, future changes may need to put MSR_EFER into the lists from
> domctl
> hypercall context.
>
> Plumb a struct vcpu
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, May 22, 2018 7:21 PM
>
> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL,
> Xen
> updates a host MSR load list entry with the current hardware value of
> MSR_DEBUGCTL. This is wrong.
>
> On VMExit, har
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, June 1, 2018 12:03 AM
>
> This is essentially a "take 2" of c/s 82540b66ce "x86/VT-x: Fix determination
> of EFER.LMA in vmcs_dump_vcpu()" because in hindight, that change was
> more
> problematic than useful.
>
> The origin
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, May 31, 2018 1:35 AM
>
> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL,
> Xen
> updates a host MSR load list entry with the current hardware value of
> MSR_DEBUGCTL.
>
> On VMExit, hardware automatic
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, May 28, 2018 10:28 PM
>
> * Command line documentation for what the option does.
> * Implement a canonicalise_addr() helper and replace the opencoded use
> in
>sign_extend_msr()
> * Canonicalise the ler pointers and pr
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, May 28, 2018 10:28 PM
>
> The host PAT value is a compile time constant, and doesn't need to be read
> out
> of hardware. Merge this if block into the previous block, which has an
> identical condition.
>
> Signed-off-by: A
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, May 28, 2018 10:28 PM
>
> paging_update_paging_modes() and vmx_vlapic_msr_changed() both
> operate on the
> VMCS being constructed. Avoid dropping and re-acquiring the reference
> multiple times.
>
Acked-by: Kevin Tian
__
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, May 28, 2018 10:28 PM
>
> The hvmloader code which used this signal was deleted 10 years ago (c/s
> 50b12df83 "x86 vmx: Remove vmxassist"). Furthermore, the value gets
> discarded
> anyway because the HVM domain builder unco
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, June 9, 2018 2:49 AM
>
> At the moment, all modifications of the MSR lists are in current context.
> However, future changes may need to put MSR_EFER into the lists from
> domctl
> hypercall context.
>
> Plumb a struct vcp
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, June 9, 2018 2:49 AM
>
> The main purpose of this patch is to only ever insert the LBR MSRs into the
> guest load/save list once, as a future patch wants to change the behaviour
> of
> vmx_add_guest_msr().
>
> The repeated
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, June 9, 2018 2:49 AM
>
> The main purpose of this change is to allow us to set a specific MSR value,
> without needing to know whether there is already a load/save list slot for it.
>
> Previously, callers wanting this pro
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, June 9, 2018 2:49 AM
>
> Currently, the VMX_MSR_GUEST type maintains completely symmetric
> guest load
> and save lists, by pointing VM_EXIT_MSR_STORE_ADDR and
> VM_ENTRY_MSR_LOAD_ADDR
> at the same page, and setting VM_EXI
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, June 9, 2018 2:49 AM
>
> Up until this point, the MSR load/save lists have only ever accumulated
> content. Introduce vmx_del_msr() as a companion to vmx_add_msr().
>
> Signed-off-by: Andrew Cooper
Reviewd-by: Kevin Tia
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, June 9, 2018 2:49 AM
>
> Intel hardware only uses 4 bits in MSR_EFER. Changes to LME and LMA are
> handled automatically via the VMENTRY_CTLS.IA32E_MODE bit.
>
> SCE is handled by ad-hoc logic in context_switch(),
> vmx_r
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, June 16, 2018 12:31 AM
>
> It is hard to reconcile the comment at the top of the loop in
> vtd_set_hwdom_mapping() with the if statement following it. This patch
> re-phrases the logic, preserving the semantics, but making it
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, June 16, 2018 12:31 AM
>
> The documentation for the iommu_inclusive_mapping Xen command line
> option
> states:
>
> "Use this to work around firmware issues providing incorrect RMRR
> entries"
>
> Unfortunately this workaro
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, August 15, 2018 7:34 PM
>
> It took till the 4.5 backports of the L1TF prereqs that gcc 8.2 finally
> noticed that the vPMU callers, not checking the function's return value,
> may consume uninitialized data. Guard against this by s
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, August 14, 2018 9:43 PM
>
> To iommu_hwdom_strict and iommu_hwdom_passthrough which is more
> descriptive of their usage. Also change their type from bool_t to
> bool.
>
> No functional change.
>
> Signed-off-by: Roger Pau Mo
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, August 14, 2018 9:44 PM
>
> Introduce a new dom0-iommu=map-inclusive generic option that
> supersedes iommu_inclusive_mapping. The previous behavior is preserved
> and the option should only be enabled by default on Intel hardw
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, August 21, 2018 3:50 PM
>
> To iommu_hwdom_strict and iommu_hwdom_passthrough which is more
> descriptive of their usage. Also change their type from bool_t to
> bool.
>
> No functional change.
>
> Signed-off-by: Roger Pau Mo
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, August 21, 2018 3:50 PM
>
> Introduce a new dom0-iommu=map-inclusive generic option that
> supersedes iommu_inclusive_mapping. The previous behavior is preserved
> and the option should only be enabled by default on Intel hardw
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, August 21, 2018 3:50 PM
>
> Several people have reported hardware issues (malfunctioning USB
> controllers) due to iommu page faults on Intel hardware. Those faults
> are caused by missing RMRR (VTd) entries in the ACPI tables.
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Friday, August 17, 2018 11:12 PM
>
> Signed-off-by: Wei Liu
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
> From: Zhenzhong Duan [mailto:zhenzhong.d...@oracle.com]
> Sent: Monday, August 20, 2018 6:43 PM
>
> Release memory allocated for drhd iommu in error path.
>
> -v2: fixup wrong parameter hiden due to my removing -Werror
>
> Signed-off-by: Zhenzhong Duan
Acked-by: Kevin Tian
_
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, August 21, 2018 8:32 PM
>
> >>> On 21.08.18 at 11:11, wrote:
> > @@ -490,10 +488,6 @@ int __init
> tboot_parse_dmar_table(acpi_table_handler dmar_handler)
> > rc = dmar_handler(dmar_table);
> > xfree(dmar_table);
> >
> > -
> From: Wei Liu
> Sent: Sunday, August 26, 2018 8:20 PM
>
> They all incorrectly named a parameter virtual address while it should
> have been linear address.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Wei Liu
Reviewed-by: Kevin Tian
___
Xen-d
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, August 28, 2018 9:12 PM
> > +valid_mask = ((1ULL << v->domain->arch.cpuid->extd.maxphysaddr) -
> 1) &
> > + (PAGE_MASK | _PAGE_AVAIL | _PAGE_PRESENT);
>
> How did you come across this list? The only vali
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Sunday, August 26, 2018 8:20 PM
>
> Functions are moved to hvm.c. Reorder makefile items while at it.
>
> Signed-off-by: Wei Liu
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xen
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Sunday, August 26, 2018 8:20 PM
>
> This requires providing stubs for a few functions which are part of
> HVM code.
>
> Signed-off-by: Wei Liu
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xe
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, August 29, 2018 1:39 AM
>
> The trailing _domain suffix is redundant, but adds to code volume. Drop it.
>
> Reflow lines as appropriate, and switch to using the new XFREE/etc
> wrappers
> where applicable.
>
> No functi
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, August 29, 2018 1:39 AM
>
> The suffix and prefix are redundant, and the name is curiously odd.
> Rename it
> to vmx_vcpu to be consistent with all the other similar structures.
>
> No functional change.
>
> Signed-off-b
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, August 29, 2018 1:39 AM
>
> The trailing _vcpu suffix is redundant, but adds to code volume. Drop it.
>
> Reflow lines as appropriate, and switch to using the new XFREE/etc
> wrappers
> where applicable.
>
> No function
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, August 29, 2018 1:39 AM
>
> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent
> with
> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all
> code
> refer to the correctly-named field
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, August 29, 2018 9:59 PM
>
> Three of the four hooks are not exposed outside of vmx.c, and all of
> them have only a single possible non-NULL value. So there's no reason to
> use hooks here - a simple set of flag indicators is suffic
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, August 30, 2018 11:47 PM
>
> On 30/08/18 15:54, Jan Beulich wrote:
> On 28.08.18 at 19:39, wrote:
> >> The suffix and prefix are redundant, and the name is curiously odd.
> Rename it
> >> to vmx_vcpu to be consistent
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, September 3, 2018 6:40 PM
>
> On 04/06/18 14:59, Andrew Cooper wrote:
> > See the code comment for the details.
> >
> > Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
___
Xen-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 3, 2018 7:47 PM
>
> >>> On 03.09.18 at 10:23, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 30 August 2018 17:00
> >>
> >> >>> On 23.08.18 at 11:46, wrote:
> >> > --- a/xen/include/xen/mm.h
> >> > +++
101 - 200 of 585 matches
Mail list logo
