> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, November 20, 2017 9:20 PM
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Jun Nakajima
> CC: Kevin Tian
> ---
> xen/arch/x86/hvm/vmx/intr.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, November 17, 2017 3:16 AM
>
> Doing so amounts to silent state corruption, and must be avoided.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Jun Nakajima
> CC: Kevin Tian
> CC: Boris Ostr
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, December 4, 2017 7:07 PM
>
> As XSAs 246 and 247 have shown, not doing so is rather dangerous.
>
> Signed-off-by: Jan Beulich
>
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xen-de
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, December 7, 2017 12:29 AM
>
> Perhaps there once was a plan to have a flush type requiring this, but
> the current SDM has no mention of such and all callers pass zero anyway.
>
> Take the opportunity and also change involved types
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, December 7, 2017 4:06 AM
>
> Since c/s 49de10f3c1718 "x86/hvm: Don't raise #GP behind the emulators
> back
> for MSR accesses", returnning X86EMUL_EXCEPTION has pushed the
> exception
> generation to the top of the call tre
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, December 7, 2017 4:06 AM
>
> They are straight aliases of the more common X86EMUL_* constants.
> While
> adjusting these, fix the case indentation where appropriate.
>
> No functional change, confirmed by diff'ing the comp
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 2, 2019 7:58 PM
>
> On 02.09.2019 13:30, Roger Pau Monne wrote:
> > Don't allow the hardware domain to access the PCI config space of
> > devices not assigned to it. Ie: the config space of iommu devices
> > in use by Xen sho
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Thursday, August 29, 2019 6:26 PM
>
> On Tue, Aug 27, 2019 at 05:23:33PM +0200, Jan Beulich wrote:
> > On 23.08.2019 07:58, Tian, Kevin wrote:
> > > > From: Roger Pau Monne [mailto:roger@citrix.com]
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Wednesday, September 4, 2019 10:20 PM
>
> So that the name implies the function is used to walk the page table
> pointer passed as parameter. Drop the parent_ prefix from the level
> parameter, since the level passed is the one matching
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, September 4, 2019 9:27 PM
>
> Drop iommu_to_drhd() altogether - there's no need for a loop here, the
> corresponding DRHD is a field in struct intel_iommu.
>
> Constify drhd_to_rhsa()'s parameter and adjust style.
>
> Signed-off-b
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, September 4, 2019 9:28 PM
>
> The two uses of pci_get_pdev_by_domain() lack proper locking, but are
> also only used to get hold of a NUMA node ID. Calculate and store the
> node ID earlier on and remove the lookups (in lieu of fixi
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, September 4, 2019 9:28 PM
>
> Use appropriate types. Drop unnecessary casts. Check for failures which
> can (at least in theory because of non-obvious breakage elsewhere)
> occur, instead of ones which really can't (map_domain_page(
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 19, 2019 6:38 PM
>
> hvm_monitor_cpuid() expects the input registers, not two of the outputs.
>
> However, once having made the necessary adjustment, the SVM and VMX
> functions are so similar that they should be folded (t
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Wednesday, September 25, 2019 12:42 AM
>
> Ping?
>
> Since I've got an Ack from Jan and Julien I think the missing Acks are
> for the Intel stuff and x86 generic and AMD by Andrew, since Jan
> explicitly expressed his Ack is only for p
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, September 13, 2019 7:10 PM
>
> This patch defines a new bit reported in the hw_cap field of struct
> xen_sysctl_physinfo to indicate whether the platform supports sharing of
> HAP page tables (i.e. the P2M) with the IOMMU. This informs
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, April 26, 2019 12:45 AM
>
> * Use XFREE() instead of opencoding it in nvmx_cpu_dead()
> * Avoid redundant evaluations of per_cpu()
> * Don't allocate vvmcs_buf at all if it isn't going to be used. It is never
>touched
> From: Tamas K Lengyel [mailto:ta...@tklengyel.com]
> Sent: Thursday, May 2, 2019 7:52 AM
>
> Currently the gs_shadow value is only cached when the vCPU is being
> scheduled
> out by Xen. Reporting this (usually) stale value through vm_event is
> incorrect,
> since it doesn't represent the actua
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, May 8, 2019 9:16 PM
>
> >>> On 08.05.19 at 15:10, wrote:
> > All of __{assign,bind,clear}_irq_vector() manipulate struct irq_desc
> > fields, and hence ought to be called with the descriptor lock held in
> > addition to vector_lock
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, May 14, 2019 8:04 PM
>
> The function passes 0 as "alloc" argument to addr_to_dma_page_maddr(),
> so -ENOMEM simply makes no sense (and its use was probably simply a
> copy-and-paste effect originating at intel_iommu_map_page()).
>
>
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, May 23, 2019 6:20 PM
>
> The various pieces of the hypercall page infrastructure have grown
> organically over time and ended up in a bit of a mess.
>
> * Rename all functions to be of the form *_init_hypercall_page(). T
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Friday, December 14, 2018 7:50 PM
>
> Block interrupts (in vmx_intr_assist()) for the duration of
> processing a sync vm_event (similarly to the strategy
> currently used for single-stepping). Otherwise, attempting
> to emulate an
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Monday, December 17, 2018 5:23 PM
>
> A subsequent patch will add semantically different versions of
> iommu_map/unmap() so, in advance of that change, this patch renames
> the
> existing functions to iommu_legacy_map/unmap() and modifi
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Friday, December 21, 2018 1:39 AM
>
> When an new altp2m view is created very early on guest boot, the
> display will freeze (although the guest will run normally). This
> may also happen on resizing the display. The reason is the
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, December 21, 2018 1:17 AM
>
> Switch parse_ept_param() to use the parse_boolean() infrastructure for
> more
> consistency with related command line parameters. Rename
> opt_pml_enabled to
> opt_ept_pml for consistency with o
> From: Julien Grall
> Sent: Saturday, December 22, 2018 12:27 AM
>
> No functional change intended.
>
> Only reasonable clean-ups are done in this patch. The rest will use _gfn
> for the time being.
>
> Signed-off-by: Julien Grall
> Acked-by: Jan Beulich
>
Reviewed-by: Kevin Tian
_
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, December 28, 2018 8:40 PM
>
> c/s fd32dcfe4c "x86/vmx: Don't leak EFER.NXE into guest context" had an
> unintended consequence on Harpertown cores which, as it turns out, don't
> load MSR_EFER fully from the MSR Load List - o
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, January 25, 2019 2:28 AM
>
> Code clearing the "Suppress VE" bit in an EPT entry isn't nececsserily
> running
> in current context. In ALTP2M_external mode, it definitely is not, and in PV
> context, vcpu_altp2m(current) act
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Monday, January 7, 2019 8:03 PM
>
> Saving and restoring the value of this MSR is currently handled by
> implementation-specific code despite it being architectural. This patch
> moves handling of accesses to this MSR from hvm.c into th
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Monday, January 7, 2019 8:03 PM
>
> ...to avoid the need for a VMCS reload when the value of
> MSR_IA32_BNDCFGS is
> read by the tool-stack.
the frequency of context switch is much higher than the
one of reading by tool-stack (at least
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Monday, January 7, 2019 8:03 PM
>
> Currently the value is saved directly in struct hvm_vcpu. This patch simply
> co-locates it with other saved MSR values. No functional change.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Kevin Tia
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Monday, January 7, 2019 8:03 PM
>
> Saving and restoring the value of this MSR is currently handled by
> implementation-specific code despite it being architectural. This patch
> moves handling of accesses to this MSR from hvm.c into th
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, July 30, 2019 10:43 PM
>
> c/s e9986b0dd "x86/vvmx: Simplify per-CPU memory allocations" had the
> wrong
> indirection on its pointer check in nvmx_cpu_up_prepare(), causing the
> VMCS-shadowing buffer never be allocated. F
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, August 9, 2019 6:39 PM
>
> TSS, LDT, and per-CPU entries all can benefit a little from also having
> their selector values defined.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, August 13, 2019 1:17 AM
>
> c/s 650c31d3af "x86/IRQ: fix locking around vector management" adjusted
> the
> locking in adjust_irq_affinity().
>
> The S3 path ends up here via iommu_resume() before interrupts are enabled,
>
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 17, 2019 1:20 AM
>
> ...rather than testing the global iommu_enabled flag and ops pointer.
>
> Now that there is a per-domain flag indicating whether the domain is
> permitted to use the IOMMU (which determines whether
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, August 20, 2019 11:38 PM
>
> The level passed to ept_invalidate_emt corresponds to the EPT entry
> passed as the mfn parameter, which is a pointer to an EPT page table,
> hence the entries in that page table will have one level
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, February 6, 2019 6:24 PM
>
> set_mmio_p2m_entry() may fail, in particular with -ENOMEM. Don't ignore
> such an error, but instead cause domain creation to fail in such a case.
>
> Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: Saturday, February 2, 2019 12:30 AM
>
> Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from
> certain
> IOMMU hook accesses") introduced iommu_ops initialized at boot time
> with data declared as __initconstrel.
>
> On Intel systems
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, February 19, 2019 1:27 AM
>
> So that it can be shared by both ept, npt and shadow code, instead of
> duplicating it.
>
> No change in functionality intended.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Paul Durrant
>
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, February 19, 2019 1:27 AM
>
> So that the specific handling can be removed from
> atomic_write_ept_entry and be shared with npt and shadow code.
>
> This commit also removes the check that prevent non-ept PVH dom0 from
> mappi
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Tuesday, February 19, 2019 10:01 PM
>
> On Tue, Feb 19, 2019 at 06:14:00AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne [mailto:roger@citrix.com]
> > > Sent: Tuesday, February 19, 2019 1:27
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, February 22, 2019 4:19 AM
>
> The logic in altp2m_vcpu_{en,dis}able_ve() and
> vmx_vcpu_update_vmfunc_ve() is
> dangerous. After #VE has been set up, the guest can balloon out and free the
> nominated GFN, after which the pr
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, February 20, 2019 6:19 AM
>
> Modificaitons to an altp2m mark the p2m as needing flushing, but this was
Modifications
> never wired up in the return-to-guest path. As a result, stale TLB entries
> can remain after resum
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, February 23, 2019 3:13 AM
>
> iremap_maddr and qinval_maddr point to the base of a block of contiguous
> RAM,
> allocated by the driver, holding the Interrupt Remapping table, and the
> Queued
> Invalidation ring.
>
> Desp
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, February 23, 2019 3:13 AM
>
> VT-d's local struct iommu is an overly-generic name, for a structure which in
> practice maps 1-to-1 with the real IOMMUs in the system.
>
> Additionally, address style issues on impacted line
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, February 23, 2019 3:13 AM
>
> It is unclear why this abstraction exists, but iommu_qi_ctrl() returns
> possibly NULL and every user unconditionally dereferences the result. In
> practice, I can't spot a path where iommu is
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, February 25, 2019 7:01 PM
>
> >>> On 25.02.19 at 11:09, wrote:
> >> -Original Message-
> > [snip]
> >> struct iommu_flush {
> >> int __must_check (*context)(void *iommu, u16 did, u16 source_id,
> >>
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, February 23, 2019 3:13 AM
>
> It is unclear why this abstraction exists, but iommu_get_flush() returns
> possibly NULL and every user unconditionally dereferences the result. In
> practice, I can't spot a path where iommu
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, February 23, 2019 3:13 AM
>
> The sole remaining member of struct intel_iommu is the drhd backpointer.
> Move
> this into struct vtd_iommu, replacing the the 'intel' pointer.
>
> This removes one dynamic memory allocation
> From: Paul Durrant
> Sent: Saturday, March 2, 2019 12:41 AM
>
> Hi,
>
> As the basis of some future development work I've put together a simple
> standalone emulator to pass through a single type 0 PCI function to a guest so
> I'm posting here in case anyone else would like a give it a try. S
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Monday, March 4, 2019 4:44 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 04 March 2019 03:01
> > To: Paul Durrant ; xen-devel (xen-
&g
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, March 28, 2019 3:53 AM
>
> This has been problematic since its introduction in Xen 4.3
>
> Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-dev
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 28, 2019 10:49 PM
>
> I'm in particular after getting rid of asm/apicdef.h, but there are more
> no longer (or perhaps never having been) used ones.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
__
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 28, 2019 10:52 PM
>
> Do away with the CPU vendor dependency, and set the init ops pointer
> based on what ACPI tables have been found.
>
> Also take the opportunity and add __read_mostly to iommu_ops.
>
> Signed-off-by: Jan
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 28, 2019 10:52 PM
>
> Introduce a respective element in struct iommu_init_ops.
>
> Take the liberty and also switch intel_iommu_supports_eim() to bool/
> true/false, to fully match the hook's type.
>
> Signed-off-by: Jan Beul
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, March 29, 2019 5:13 PM
>
> >>> On 28.03.19 at 18:37, wrote:
> > On 28/03/2019 14:53, Jan Beulich wrote:
> >> @@ -35,6 +35,8 @@ void print_vtd_entries(struct iommu *iom
> >> keyhandler_fn_t vtd_dump_iommu_info;
> >>
> >> bool intel_i
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 28, 2019 10:55 PM
>
> Move this into iommu_hardware_setup() and make that function non-
> inline. Move its declaration into common code.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
__
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, April 2, 2019 9:17 PM
>
> >>> On 02.04.19 at 05:24, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, March 29, 2019 5:13 PM
> >>
> >> >>> On 28.03.19 at 18:37, wrote:
> >> > On 28/03/2019 14:53, Jan Beuli
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, April 2, 2019 8:57 PM
>
> In x2APIC mode it is 32 bits wide. Not having returned the full value
> was mostly benign: We never modify the ID based on its original value;
> full new values get written at all times. It was "just" debug l
> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> Sent: Thursday, April 4, 2019 10:42 PM
>
> Commit fd32dcfe ("x86/vmx: Don't leak EFER.NXE into guest context")
> introduced a regression on Harpertown and earlier cores (Gen 1 VT-x)
> where as soon as guest EFER becomes equal to Xen EFER
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, April 5, 2019 3:02 PM
>
> Initially I had just noticed the unnecessary indirection in the call
> from pi_update_irte(). The generic wrapper having an iommu_intremap
> conditional made me look at the setup code though. So first of all
>
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, April 5, 2019 7:30 PM
>
> >>> On 14.03.19 at 14:51, wrote:
> > Saving and restoring the value of this MSR is currently handled by
> > implementation-specific code despite it being architectural. This patch
> > moves handling of access
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, April 8, 2019 7:17 PM
>
> This can't be folded into the resume hook, as that runs before bringin
> back up APs, but the affinity adjustment wants to happen with all CPUs
> back online. Hence a separate hook is needed such that AMD can
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, April 15, 2019 8:03 PM
>
> * Fix the shim build by providing a !CONFIG_HVM declaration for
>hvm_get_guest_bndcfgs(), and removing the introduced
>ASSERT(is_hvm_domain(d))'s. They are needed for DCE to keep the build
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Thursday, November 21, 2019 5:26 PM
>
> On Mon, Nov 18, 2019 at 05:00:29PM +0100, Jan Beulich wrote:
> > On 18.11.2019 15:20, Roger Pau Monné wrote:
> > > On Mon, Nov 18, 2019 at 03:00:00PM +0100, Jan Beulich wrote:
> > >> On 18.11.201
> From: Paul Durrant [mailto:pdurr...@amazon.com]
> Sent: Wednesday, November 20, 2019 8:09 PM
>
> This patch introduces a new iommu_op to facilitate a per-implementation
> quarantine set up, and then further code for x86 implementations
> (amd and vtd) to set up a read/wrote scratch page to serve
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, November 22, 2019 6:16 AM
>
> The VT-x task switch handler adds inst_len to rip before calling
> hvm_task_switch(). This causes early faults to be delivered to the guest
> with
> trap semantics, and break restartibility.
>
> From: Roger Pau Monné
> Sent: Thursday, November 21, 2019 5:26 PM
>
> On Mon, Nov 18, 2019 at 05:00:29PM +0100, Jan Beulich wrote:
> > On 18.11.2019 15:20, Roger Pau Monné wrote:
> > > On Mon, Nov 18, 2019 at 03:00:00PM +0100, Jan Beulich wrote:
> > >> On 18.11.2019 14:46, Roger Pau Monné wro
> From: Roger Pau Monné
> Sent: Monday, November 18, 2019 10:56 PM
>
> On Mon, Nov 18, 2019 at 03:19:50PM +0100, Jan Beulich wrote:
> > On 18.11.2019 15:03, Roger Pau Monné wrote:
> > > On Mon, Nov 18, 2019 at 01:26:46PM +0100, Jan Beulich wrote:
> > >> On 18.11.2019 11:16, Roger Pau Monne wrote
> From: Roger Pau Monne
> Sent: Tuesday, November 26, 2019 9:27 PM
>
> When using posted interrupts on Intel hardware it's possible that the
> vCPU resumes execution with a stale local APIC IRR register because
> depending on the interrupts to be injected vlapic_has_pending_irq
> might not be cal
> From: Jan Beulich
> Sent: Wednesday, November 27, 2019 12:59 AM
>
> On 26.11.2019 17:47, Roger Pau Monné wrote:
> > On Tue, Nov 26, 2019 at 05:32:04PM +0100, Jan Beulich wrote:
> >> On 26.11.2019 14:26, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/hvm/vmx/vmx.c
> >>> +++ b/xen/arch/x86/hvm/
> From: Andrew Cooper
> Sent: Wednesday, December 4, 2019 6:31 AM
>
> VT-x updates RF before vmexit, so eflags written into the outgoing TSS
> happens
> to be correct. SVM does not update RF before vmexit, and instead provides
> it
> via a bit in exitinfo2.
>
> In practice, needing RF set in th
> From: Jan Beulich
> Sent: Tuesday, December 3, 2019 5:36 PM
>
> On 28.11.2019 12:32, Jürgen Groß wrote:
> > On 28.11.19 12:17, Jan Beulich wrote:
> >> On 27.11.2019 18:11, Paul Durrant wrote:
> >>> This patch introduces a new iommu_op to facilitate a per-
> implementation
> >>> quarantine set u
> From: Jürgen Groß
> Sent: Friday, December 13, 2019 11:36 PM
>
> On 13.12.19 15:45, Jan Beulich wrote:
> > On 13.12.2019 15:24, Jürgen Groß wrote:
> >> On 13.12.19 15:11, Jan Beulich wrote:
> >>> On 13.12.2019 14:46, Jürgen Groß wrote:
> On 13.12.19 14:38, Jan Beulich wrote:
> > On 13.
> From: Roger Pau Monné
> Sent: Friday, December 13, 2019 10:13 PM
>
> On Fri, Dec 13, 2019 at 01:53:29PM +0100, Jan Beulich wrote:
> > Containing still in flight DMA was introduced to work around certain
> > devices / systems hanging hard upon hitting an IOMMU fault. Passing
> > through (such) d
> From: Jin Nan Wang
> Sent: Monday, December 16, 2019 1:48 PM
>
> Fix a issue when user disable ETP exec-sp, xen missed a prompt
> log in dmesg.
>
> Signed-off-by: James Wang
> ---
> xen/arch/x86/hvm/vmx/vmx.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/xen/ar
> From: Tian, Kevin
> Sent: Monday, December 16, 2019 1:58 PM
>
> > From: Jürgen Groß
> > Sent: Friday, December 13, 2019 11:36 PM
> >
> > On 13.12.19 15:45, Jan Beulich wrote:
> > > On 13.12.2019 15:24, Jürgen Groß wrote:
> > >> On 13.12.19
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, October 23, 2019 10:00 PM
>
> On 11.10.2019 17:33, Roger Pau Monné wrote:
> > On Fri, Oct 11, 2019 at 04:02:53PM +0100, Andrew Cooper wrote:
> >> The virtual address of the base of the IOMMU's regsters is not useful for
> >> diagno
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, October 25, 2019 1:28 AM
>
> * Initialise all spinlock fields together
> * No need for an atomic set_bit() to initialise domid_bitmap
> * Avoid using partial-line printk()'s.
> * Style fixes (too many, and too few spaces)
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, October 28, 2019 11:02 PM
>
> Cross reference and list each errata, now that they are published.
>
> These errata are specific to Haswell/Broadwell. They should have model
> and
> vendor checks, as Intel isn't the only vend
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, October 28, 2019 11:02 PM
>
> At the time of fixing c/s 20f1976b44, no obvious errata had been published,
> and BDF14 looked like the most obvious candidate. Subsequently, BDF93
> has
> been published and it is obviously thi
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Thursday, October 31, 2019 11:23 PM
>
> On Thu, Oct 31, 2019 at 07:52:23AM -0700, Joe Jin wrote:
> > On 10/31/19 1:01 AM, Jan Beulich wrote:
> > > On 30.10.2019 19:01, Joe Jin wrote:
> > >> On 10/30/19 10:23 AM, Roger Pau Monné wrote:
>
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Monday, November 4, 2019 5:47 PM
>
> On Sat, Nov 02, 2019 at 07:48:06AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monné [mailto:roger@citrix.com]
> > > Sent: Thursday, October 31, 2019 11:23
> -Original Message-
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Friday, November 8, 2019 6:20 PM
> To: Tian, Kevin
> Cc: Joe Jin ; Jan Beulich ;
> Andrew Cooper ; xen-
> de...@lists.xenproject.org; Juergen Gross ; Wei Liu
>
> Subject: Re:
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, November 8, 2019 9:34 PM
>
> When using posted interrupts and the guest migrates MSI from vCPUs Xen
> needs to flush any pending PIRR vectors on the previous vCPU, or else
> those vectors could get wrongly injected at a later po
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, November 23, 2018 4:30 PM
>
> The backport of cd53023df9 ("x86/msr: Virtualise MSR_SPEC_CTRL.SSBD for
> guests to use") did not mirror the PV side change into the HVM (VMX-
> specific) code path.
>
> Signed-off-by: Jan Beulich
Acked
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: Wednesday, November 28, 2018 6:06 PM
>
> Some prototypes in include/asm-x86/hvm/vmx/vmx.h have no related
> implementation. Remove them.
>
> Signed-off-by: Juergen Gross
Acked-by: Kevin Tian
___
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, November 20, 2018 10:37 PM
>
> With PVRDTSCP mode removed, handling of MSR_TSC_AUX can move into
> the common
> code. Move its storage into struct vcpu_msrs (dropping the HVM-specific
> msr_tsc_aux), and add an RDPID featur
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Wednesday, November 28, 2018 5:20 PM
>
> On Thu, Nov 01, 2018 at 09:18:14AM +, Andrew Cooper wrote:
> > On 01/11/2018 00:40, Tian, Kevin wrote:
> > >> From: Tian, Kevin
> > >&g
> 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:
> > Hello,
> >
> > I realise this is an old CPU, but I've I've encountered a weird failure
> > on it.
> >
> > Specifically:
> >
>
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Monday, October 15, 2018 6:30 PM
> (XEN) [22642] POWERTYPE 4
> (XEN) [22643] IDLE PPR 0x0020
> (XEN)IRR
> 00
> 00
> (XEN)
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Wednesday, December 12, 2018 7:25 PM
>
> On Wed, Dec 12, 2018 at 10:36:44AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monné [mailto:roger@citrix.com]
> > > Sent: Monday, October 15, 2018 6:30
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Wednesday, December 12, 2018 8:18 PM
>
> On Wed, Dec 12, 2018 at 11:48:52AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monné [mailto:roger@citrix.com]
> > > Sent: Wednesday, December 12, 2018 7:25
btw can you also capture ISR/IRR/PPR right before local_irq_enable()?
though I didn't see a reason why code in-between may impact those
bits, it doesn't hurt to capture the context right before interrupt is
raised. :-)
> -Original Message-
> From: Tian, Kevin
> Sent:
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, December 1, 2018 1:07 AM
>
> For both VT-x and SVM, the RDTSCP intercept will trigger if the pipeline
> supports the instruction, but the guest may have not have rdtscp in its
> featureset. Bring the vmexit handlers in lin
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Thursday, December 6, 2018 11:34 PM
>
> A subsequent patch will add semantically different versions of
> iommu_map/unmap() so, in advance of that change, this patch renames
> the
> existing functions to iommu_legacy_map/unmap() and modi
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Thursday, December 6, 2018 11:34 PM
>
> This patch removes any implicit flushing that occurs in the implementation
> of map and unmap operations and adds new iommu_map/unmap()
> wrapper
> functions. To maintain sematics of the iommu_leg
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, December 8, 2018 4:07 AM
> nested vmx mode
>
> By default on capable hardware,
> SECONDARY_EXEC_ENABLE_VMCS_SHADOWING is
> activated unilaterally. The VMCS Link pointer is initialised to ~0, but the
> VMREAD/VMWRITE bitmap
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Tuesday, December 11, 2018 8:33 PM
>
> > In any case, I think you want to rename the function and/or document
> > more that expected behavior.
>
> You're right, I should probably rename that function / variable to
> better reflect
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, December 13, 2018 4:37 PM
>
> >>> On 13.12.18 at 02:28, wrote:
> > btw I checked your original mail:
> >
> > (XEN)[] mwait-idle.c#mwait_idle+0x2a5/0x381
> > xen/arch/x86/cpu/mwait-idle.c:802
> >
> >788 if (cpu_i
1 - 100 of 585 matches
Mail list logo
