> From: Jan Beulich
> Sent: Tuesday, July 6, 2021 12:09 AM
>
> This also includes the two p2m related fields.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -94,7 +94,9 @@ static int p2m_initialise(struct domain
>
> From: Jan Beulich
> Sent: Tuesday, August 3, 2021 7:14 PM
>
> While for 5500 and 5520 chipsets only B3 and C2 are mentioned in the
> spec update, X58's also mentions B2, and searching the internet suggests
> systems with this stepping are actually in use. Even worse, for X58
> erratum #69 is ma
> From: Kevin Stefanov
> Sent: Monday, August 16, 2021 8:43 PM
>
> Also fix stray usage in VT-d.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Kevin Stefanov
Reviewed-by: Kevin Tian
> ---
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: "Roger Pau Monné"
> CC: Wei Liu
> CC: Kevin Tian
>
> From: Jan Beulich
> Sent: Thursday, August 19, 2021 4:06 PM
>
> While for context cache entry flushing use of did 0 is indeed correct
> (after all upon reading the context entry the IOMMU wouldn't know any
> domain ID if the entry is not present, and hence a surrogate one needs
> to be used), f
> From: Roger Pau Monne
> Sent: Wednesday, December 14, 2022 12:31 AM
>
> Introduce a small helper to OR VMX_INTR_SHADOW_NMI in
> GUEST_INTERRUPTIBILITY_INFO in order to help dealing with the NMI
> unblocked by IRET case. Replace the existing usage in handling
> EXIT_REASON_EXCEPTION_NMI and als
> From: Roger Pau Monne
> Sent: Wednesday, December 14, 2022 12:31 AM
>
> Add support for enabling guest Bus Lock Detection on Intel systems.
> Such detection works by triggering a vmexit, which ought to be enough
> of a pause to prevent a guest from abusing of the Bus Lock.
>
> Add an extra Xen
> From: Andrew Cooper
> Sent: Monday, January 9, 2023 8:08 PM
>
> There is no point repeating this calculation at runtime, especially as it is
> in the fallback path of the WRSMR/RDMSR handlers.
>
> Move the infrastructure higher in vmx.c to avoid forward declarations,
> renaming last_branch_msr
> From: Andrew Cooper
> Sent: Monday, January 9, 2023 8:08 PM
>
> Ice Lake (server at least) has both Arch LBR and model-specific LBR. Sapphire
> Rapids does not have model-specific LBR at all. I.e. On SPR and later,
> model_specific_lbr will always be NULL, so we must make changes to avoid
> r
> From: Roger Pau Monne
> Sent: Saturday, May 29, 2021 1:40 AM
>
> This is an EPT specific function, so it shouldn't live in the generic
> mtrr file. Such movement is also needed for future work that will
> require passing a p2m_type_t parameter to epte_get_entry_emt, and
> making that type visib
> From: Roger Pau Monne
> Sent: Saturday, May 29, 2021 1:40 AM
>
> Force WB type for grants and foreign pages. Those are usually mapped
> over unpopulated physical ranges in the p2m, and those ranges would
> usually be UC in the MTRR state, which is unlikely to be the correct
> cache attribute. I
> From: Jan Beulich
> Sent: Wednesday, June 23, 2021 2:52 PM
>
> On 09.06.2021 11:25, Jan Beulich wrote:
> > A number of further adjustments were left out of the XSA, for not
> > being a security concern (anymore in some of the cases, with the
> > changes put in place there). This is the collecti
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:28 PM
>
> When
> - flushes (supposedly not possible anymore after XSA-373),
> - secondary mappings for legacy PCI devices behind bridges,
> - secondary mappings for chipset quirks, or
> - find_upstream_bridge() invocations
> fail, the succ
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:28 PM
>
> When an earlier error occurred, cleaning up the domid mapping data is
> wrong, as references likely still exist. The only exception to this is
> when the actual unmapping worked, but some flush failed (supposedly
> impossible after X
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:29 PM
>
> If there is any way for one fault to be left set in the recording
> registers, there's no reason there couldn't also be multiple ones. If
> PPF set set (being the OR or all F fields), simply loop over the entire
> range of fault reco
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:29 PM
>
> While no longer an immediate problem with flushes no longer timing out,
> errors (if any) get properly reported by iommu_flush_iotlb_{dsi,psi}().
> Overwriting such an error with, perhaps, a success indicator received
> from another I
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:30 PM
>
> Introduce a helper function to reduce redundancy. Take the opportunity
> to express the logic without using the somewhat odd QINVAL_ENTRY_ORDER.
> Also take the opportunity to uniformly unmap after updating queue tail
> and dropping
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:30 PM
>
> Replace uses of QINVAL_ENTRY_ORDER and QINVAL_INDEX_SHIFT, such that
> the constants can be dropped. Move the remaining QINVAL_* ones to the
> single source file using them.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
> From: Roger Pau Monne
> Sent: Wednesday, July 26, 2023 8:55 PM
>
> Preparatory change to unify the IO-APIC pin variable name between
> io_apic_read_remap_rte() and amd_iommu_ioapic_update_ire(), so that
> the local variable can be made a function parameter with the same name
> across vendors.
>
> From: Roger Pau Monne
> Sent: Friday, July 28, 2023 5:57 PM
>
> So that the remapping entry can be updated atomically when possible.
>
> Doing such update atomically will avoid Xen having to mask the IO-APIC
> pin prior to performing any interrupt movements (ie: changing the
> destination and
> From: Roger Pau Monne
> Sent: Thursday, May 25, 2023 4:09 PM
>
> Fix two issues related to leaf address lookups in VT-d:
>
> * When translating an address that falls inside of a superpage in the
> IOMMU page tables the fetching of the PTE value wasn't masking of the
> contiguous related da
> From: Andrew Cooper
> Sent: Wednesday, April 27, 2022 1:52 AM
>
> Hello,
>
> Edvin has found a machine with some very weird properties. It is an HP
> ProLiant BL460c Gen8 with:
>
> \-[:00]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2
> +-01.0-[11]--
> +-01.1-
> From: Lengyel, Tamas
> Sent: Friday, March 25, 2022 9:33 PM
>
> During VM forking and resetting a failed vmentry has been observed due
> to the guest non-register state going out-of-sync with the guest register
> state. For example, a VM fork reset right after a STI instruction can trigger
> th
> From: Jan Beulich
> Sent: Monday, April 25, 2022 4:43 PM
>
> When a page table ends up with no present entries left, it can be
> replaced by a non-present entry at the next higher level. The page table
> itself can then be scheduled for freeing.
>
> Note that while its output isn't used there
> From: Jan Beulich
> Sent: Monday, April 25, 2022 4:45 PM
>
> With iommu_flush_iotlb_all() gone, iommu_flush_iotlb_pages() is merely a
> wrapper around the not otherwise called iommu_flush_iotlb(). Fold both
> functions.
>
> No functional change intended.
>
> Signed-off-by: Jan Beulich
Revie
> From: Jan Beulich
> Sent: Monday, April 25, 2022 4:45 PM
>
> This way intel_iommu_unmap_page() ends up quite a bit more similar to
> intel_iommu_map_page().
>
> No functional change intended.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
> ---
> v4: New.
>
> --- a/xen/drivers/pa
> From: Jan Beulich
> Sent: Thursday, May 19, 2022 8:20 PM
>
> On 22.04.2022 11:58, Jan Beulich wrote:
> > EPT is of no interest when !HVM. While I'm observing gcc11 to fully
> > eliminate the function, older gcc's DCE looks to not be as good. Aid the
> > compiler in eliminating the accesses of o
> From: Tamas K Lengyel
> Sent: Wednesday, May 18, 2022 11:02 PM
>
> On Thu, May 12, 2022 at 9:47 AM Tamas K Lengyel
> wrote:
> >
> > On Wed, May 4, 2022 at 9:12 AM Tamas K Lengyel
> wrote:
> > >
> > > On Wed, Apr 27, 2022 at 11:51 AM Tamas K Lengyel
> > > wrote:
> > > >
> > > > Add monitor ev
> From: Jan Beulich
> Sent: Wednesday, May 18, 2022 6:26 PM
>
> On 10.05.2022 16:30, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:42:50AM +0200, Jan Beulich wrote:
> >> When a page table ends up with no present entries left, it can be
> >> replaced by a non-present entry at the next highe
> From: Roger Pau Monné
> Sent: Tuesday, June 7, 2022 6:06 PM
>
> On Tue, Jun 07, 2022 at 09:43:25AM +0200, Jan Beulich wrote:
> > On 03.06.2022 16:46, Roger Pau Monné wrote:
> > > On Fri, Jun 03, 2022 at 02:49:54PM +0200, Jan Beulich wrote:
> > >> On 26.05.2022 13:11, Roger Pau Monne wrote:
> > >
+Chenyi/Xiaoyao who worked on the KVM support. Presumably
similar opens have been discussed in KVM hence they have the
right background to comment here.
> From: Roger Pau Monne
> Sent: Thursday, May 26, 2022 7:12 PM
>
> Under certain conditions guests can get the CPU stuck in an unbounded
> loop
> From: Jan Beulich
> Sent: Thursday, December 2, 2021 5:19 PM
>
> On 01.12.2021 15:39, Andrew Cooper wrote:
> > On 01/12/2021 09:40, Jan Beulich wrote:
> >> The actual function should always have lived in core x86 code; move it
> >> there, replacing get_cache_line_size() by readily available (ex
> From: Jan Beulich
> Sent: Thursday, December 2, 2021 4:48 PM
>
> On 01.12.2021 14:02, Andrew Cooper wrote:
> > On 01/12/2021 09:41, Jan Beulich wrote:
> >> --- a/xen/drivers/passthrough/vtd/iommu.c
> >> +++ b/xen/drivers/passthrough/vtd/iommu.c
> >> @@ -591,7 +591,8 @@ static int __must_check i
> From: Jan Beulich
> Sent: Friday, December 3, 2021 6:41 PM
>
> When an IOMMU implements the full 16 bits worth of DID in context
> entries, there's no point going through a memory base translation table.
> For IOMMUs not using Caching Mode we can simply use the domain IDs
> verbatim, while for
> From: Jan Beulich
> Sent: Thursday, December 9, 2021 11:52 PM
>
> While putting together patch 1, I've noticed two further aspects to
> clean up a little.
>
> 1: properly parenthesize a number of macros
> 2: use DMA_TLB_IVA_ADDR()
> 3: shorten vtd_flush_{context,iotlb}_reg()
>
Reviewed-by: K
> From: Jan Beulich
> Sent: Wednesday, December 1, 2021 12:11 AM
>
> ept_free_entry() gets called after a flush - if one is necessary in the
> first place - was already issued. That behavior is similar to NPT, which
> also doesn't have any further flush in p2m_free_entry(). (Furthermore,
> the fu
> From: Jan Beulich
> Sent: Friday, March 15, 2024 12:23 AM
>
> We'd like to thank Kevin, so far the VT-d maintainer, for his past
> contributions, while at the same time we'd like to reflect reality as it
> has been for quite some time. Have VT-d maintainership (and for symmetry
> also AMD IOMMU
> From: Jan Beulich
> Sent: Monday, March 4, 2024 5:28 PM
>
> We'd like to thank the VT-x maintainers for their past contributions,
> while at the same time we'd like to reflect reality as it has been for
> quite some time. Have VT-x maintainership (and for symmetry also AMD
> SVM's) fall back to
> From: Paul Durrant
> Sent: Wednesday, November 25, 2020 3:08 AM
>
> From: Paul Durrant
>
> ... with macro evaluations, now that it is available.
>
> A recent patch imported the sizeof_field() macro from Linux. This patch
> makes
> use of it in places where the construct is currently open-cod
> From: Julien Grall
> Sent: Thursday, November 19, 2020 10:52 PM
>
> From: Julien Grall
>
> When booting Xen with CONFIG_USBAN=y on Sandy Bridge, UBSAN will
> throw
> the following splat:
>
> (XEN)
>
>
> (XEN) U
> From: Paul Durrant
> Sent: Friday, November 20, 2020 9:25 PM
>
> From: Paul Durrant
>
> This makes the code a little easier to read and also makes it more consistent
> with iremap_entry.
>
> Also take the opportunity to tidy up the implementation of
> device_in_domain().
>
> Signed-off-by:
> From: Paul Durrant
> Sent: Friday, November 20, 2020 9:25 PM
>
> From: Paul Durrant
>
> This removes the need for much shifting, masking and several magic
> numbers.
> On the whole it makes the code quite a bit more readable.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Kevin Tian
> ---
> From: Beulich
> Sent: Saturday, November 28, 2020 12:02 AM
>
> On 20.11.2020 14:24, Paul Durrant wrote:
> > @@ -709,20 +709,23 @@ static void dma_pte_clear_one(struct domain
> *domain, uint64_t addr,
> > page = (struct dma_pte *)map_vtd_domain_page(pg_maddr);
> > pte = page + address_l
> From: Jan Beulich
> Sent: Saturday, November 28, 2020 12:46 AM
>
> Containing still in flight DMA was introduced to work around certain
> devices / systems hanging hard upon hitting a "not-present" IOMMU fault.
> Passing through (such) devices (on such systems) is inherently insecure
> (as gues
> From: Jan Beulich
> Sent: Monday, November 30, 2020 3:35 PM
>
> On 30.11.2020 07:13, Tian, Kevin wrote:
> >> From: Jan Beulich
> >> Sent: Saturday, November 28, 2020 12:46 AM
> >>
> >> @@ -1316,11 +1316,32 @@ boolean (e.g. `iommu=no`) can overr
> From: Jan Beulich
> Sent: Monday, November 30, 2020 5:46 PM
>
> On 30.11.2020 04:06, Tian, Kevin wrote:
> >> From: Paul Durrant
> >> Sent: Friday, November 20, 2020 9:25 PM
> >>
> >> From: Paul Durrant
> >>
> >> This makes th
> From: Roger Pau Monne
> Sent: Wednesday, January 13, 2021 1:33 AM
>
> Current interrupt pass though code will setup a timer for each
> interrupt injected to the guest that requires an EOI from the guest.
> Such timer would perform two actions if the guest doesn't EOI the
> interrupt before a gi
> From: Jan Beulich
> Sent: Monday, August 30, 2021 10:22 PM
>
> VT-d spec 3.2 converted this bit (back) to reserved. Since there's no
> use of it anywhere in the tree, simply rename it and adjust its comment.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/include/asm-
> From: Jan Beulich
> Sent: Tuesday, August 24, 2021 10:28 PM
>
> map_domain_page() et al never fail; no need to check their return values
> against NULL, and no need to carry dead printk()s.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/drivers/passthrough/amd/pci_am
> From: Jan Beulich
> Sent: Tuesday, August 24, 2021 10:29 PM
>
> On 24.08.2021 16:26, Jan Beulich wrote:
> > For one none of the three IOMMU implementations on Arm specify a
> dumping
> > hook. Generalize VT-d's "don't dump shared page tables" to cover for
> > this.
> >
> > Further in the past I
> From: Jan Beulich
> Sent: Tuesday, August 24, 2021 10:27 PM
>
> Besides the addresses this is the next crucial bit of information one
> might be after.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/
> From: Jan Beulich
> Sent: Tuesday, August 24, 2021 10:18 PM
>
> Generic code will use this information to determine what order values
> can legitimately be passed to the ->{,un}map_page() hooks. For now all
> ops structures simply get to announce 4k mappings (as base page size),
> and there is
> From: Jan Beulich
> Sent: Tuesday, August 24, 2021 10:19 PM
>
> Or really, in the case of ->map_page(), accommodate it in th existing
> "flags" parameter. All call sites will pass 0 for now.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/drivers/passthrough/amd/iommu
> From: Jan Beulich
> Sent: Wednesday, September 15, 2021 8:42 PM
>
> Kevin,
>
> On 24.08.2021 16:27, Jan Beulich wrote:
> > map_domain_page() et al never fail; no need to check their return values
> > against NULL, and no need to carry dead printk()s.
> >
> > Signed-off-by: Jan Beulich
>
> ma
> From: Jan Beulich
> Sent: Wednesday, September 15, 2021 5:12 PM
>
> If devices are to be skipped anyway (which is the case in particular for
> host bridges), there's no point complaining about a missing DRHD (and
> hence a missing association with an IOMMU).
>
> While there convert assignments
> From: Jan Beulich
> Sent: Wednesday, September 15, 2021 5:13 PM
>
> Whether to clear an IOMMU's bit in the domain's bitmap should depend on
> all devices the domain can control. For the hardware domain this
> includes hidden devices, which are associated with DomXEN.
>
> While touching related
> From: Jan Beulich
> Sent: Wednesday, September 15, 2021 5:13 PM
>
> Doing the cleanup also for phantom devices is at best redundant with
> doing it for the corresponding real device. I couldn't force myself into
> checking all the code paths whether it really is: It seems better to
> explicitly
> From: Jan Beulich
> Sent: Friday, September 17, 2021 7:00 PM
>
> Whether to clear an IOMMU's bit in the domain's bitmap should depend on
> all devices the domain can control. For the hardware domain this
> includes hidden devices, which are associated with DomXEN.
>
> While touching related lo
> From: Jan Beulich
> Sent: Friday, September 17, 2021 7:00 PM
>
> We shouldn't silently truncate respective values.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
> ---
> Strictly speaking we shouldn't use uint_t here at all. I wasn't sure
> though whether going straight to unsigned
> From: Jan Beulich
> Sent: Wednesday, August 16, 2023 5:52 PM
>
> Old gcc won't cope with initializers involving unnamed struct/union
> fields.
>
> Fixes: 3e033172b025 ("x86/iommu: pass full IO-APIC RTE for remapping table
> update")
> Signed-off-by: Jan Beulich
>
Reviewed-by: Kevin Tian
> From: Andrew Cooper
> Sent: Thursday, April 6, 2023 5:53 AM
>
> At the time of XSA-170, the x86 instruction emulator was genuinely broken.
> It
> would load arbitrary values into %rip and putting a check here probably was
> the best stopgap security fix. It should have been reverted following
> From: Jan Beulich
> Sent: Thursday, February 25, 2021 4:44 PM
>
> On 22.02.2021 11:56, Jan Beulich wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -428,6 +428,14 @@ static void vmx_domain_relinquish_resour
> > vmx_free_vlapic_mapping(d);
> > }
> >
>
> From: Jan Beulich
> Sent: Thursday, February 11, 2021 1:04 AM
>
> On 10.02.2021 18:00, Andrew Cooper wrote:
> > On 10/02/2021 16:48, Jan Beulich wrote:
> >> The address of this page is used by the CPU only to recognize when to
> >> instead access the virtual APIC page instead. No accesses would
> From: Roger Pau Monné
> Sent: Thursday, February 11, 2021 8:27 PM
>
> On Thu, Feb 11, 2021 at 12:22:41PM +0100, Jan Beulich wrote:
> > On 11.02.2021 12:16, Roger Pau Monné wrote:
> > > On Thu, Feb 11, 2021 at 11:36:59AM +0100, Jan Beulich wrote:
> > >> On 11.02.2021 09:45, Roger Pau Monné wrote
> From: Jan Beulich
> Sent: Monday, February 22, 2021 6:57 PM
>
> The address of this page is used by the CPU only to recognize when to
> access the virtual APIC page instead. No accesses would ever go to this
> page. It only needs to be present in the (CPU) page tables so that
> address translat
> From: Julien Grall
> Sent: Friday, February 26, 2021 6:57 PM
>
> From: Julien Grall
>
> The new x86 IOMMU page-tables allocator will release the pages when
> relinquishing the domain resources. However, this is not sufficient
> when the domain is dying because nothing prevents page-table to b
> From: Julien Grall
> Sent: Friday, February 26, 2021 6:57 PM
>
> From: Julien Grall
>
> The new per-domain IOMMU page-table allocator will now free the
> page-tables when domain's resources are relinquished. However, the
> per-domain IOMMU structure will still contain a dangling pointer to
>
> From: Jan Beulich
> Sent: Monday, March 1, 2021 4:16 PM
>
> On 01.03.2021 03:18, Tian, Kevin wrote:
> >> From: Roger Pau Monné
> >> Sent: Thursday, February 11, 2021 8:27 PM
> >>
> >> On Thu, Feb 11, 2021 at 12:22:41PM +0100, Jan Beulich wrote:
> From: Jan Beulich
> Sent: Monday, March 1, 2021 5:59 PM
>
> On 01.03.2021 09:30, Tian, Kevin wrote:
> >> From: Jan Beulich
> >> Sent: Monday, March 1, 2021 4:16 PM
> >>
> >> On 01.03.2021 03:18, Tian, Kevin wrote:
> >>>> From: Ro
> From: Igor Druzhinin
> Sent: Monday, March 8, 2021 3:00 PM
>
> BIOS might pass control to Xen leaving QI and/or IR in enabled and/or
> partially configured state. In case of x2APIC code path where EIM is
> enabled early in boot - those are correctly disabled by Xen before any
> attempt to confi
> From: Roger Pau Monne
> Sent: Thursday, March 11, 2021 5:59 PM
>
> Introduce an option to allow selecting a behavior similar to the pre
> Xen 4.15 one for accesses to MSRs not explicitly handled. Since commit
> 84e848fd7a162f669 and 322ec7c89f6640e accesses to MSRs not explicitly
> handled by X
> From: Jan Beulich
> Sent: Thursday, March 18, 2021 6:12 PM
>
> None of these are regressions afaict, so considering how late we are
> in the 4.15 process, I can see reasons to not take any of these. All
> of them are backporting candidates though, imo.
>
> 1: correct off-by-1 in number-of-IOMM
> From: Jan Beulich
> Sent: Thursday, April 1, 2021 4:43 PM
>
> This is effectively the other "half" of what was submitted as 4.15
> candidates in "[PATCH 0/4][4.15?] VT-d: mostly S3 related corrections".
>
> 1: improve save/restore of registers across S3
> 2: don't open-code dmar_readl()
> 3: b
> From: Jan Beulich
> Sent: Monday, April 12, 2021 7:34 PM
> Not having direct_mmio (used only once anyway) as a local variable gets
> the epte_get_entry_emt() invocation here in better sync with the other
> ones. While at it also reduce ipat's scope.
>
> Signed-off-by: Jan Beulich
Reviewed-by:
> From: Igor Druzhinin
> Sent: Thursday, April 15, 2021 6:04 PM
>
> This MSR exists since Nehalem / Silvermont and is actively used by Linux,
> for instance, to improve sampling efficiency.
>
> Signed-off-by: Igor Druzhinin
Reviewed-by: Kevin Tian
> ---
> Changes in v5:
> - added Silvermont+
> From: Igor Druzhinin
> Sent: Thursday, April 15, 2021 6:04 PM
>
> LBR, C-state MSRs should correspond to Ice Lake desktop according to
> SDM rev. 74 for both models.
>
> Ice Lake-SP is known to expose IF_PSCHANGE_MC_NO in
> IA32_ARCH_CAPABILITIES MSR
> (as advisory tells and Whitley SDP confir
> From: Igor Druzhinin
> Sent: Wednesday, April 14, 2021 1:25 AM
>
> Version 5 is backwards compatible with version 3. This allows to enable
> vPMU on Ice Lake CPUs.
>
> Signed-off-by: Igor Druzhinin
Reviewed-by: Kevin Tian
> ---
> xen/arch/x86/cpu/vpmu_intel.c | 7 ---
> 1 file changed
> From: Jan Beulich
> Sent: Wednesday, April 21, 2021 5:23 PM
>
> On 20.04.2021 18:17, Roger Pau Monné wrote:
> > On Tue, Apr 20, 2021 at 05:38:51PM +0200, Jan Beulich wrote:
> >> On 20.04.2021 17:08, Roger Pau Monné wrote:
> >>> On Thu, Apr 02, 2020 at 04:06:06AM +0800, Chao Gao wrote:
> --
> From: Jan Beulich
> Sent: Friday, April 23, 2021 6:53 PM
>
> The address of this page is used by the CPU only to recognize when to
> access the virtual APIC page instead. No accesses would ever go to this
> page. It only needs to be present in the (CPU) page tables so that
> address translation
> From: Jan Beulich
> Sent: Wednesday, April 26, 2023 8:58 PM
>
> Both have separate enable bits, which are optional. While on real
> hardware we can perhaps expect these VMX controls to be available if
> (and only if) the base CPU feature is available, when running
> virtualized ourselves this m
> From: Jan Beulich
> Sent: Wednesday, April 26, 2023 8:58 PM
>
> When either feature is available in hardware, but disabled for a guest,
> the respective insn would better cause #UD if attempted to be used.
>
> Signed-off-by: Jan Beulich
>
Reviewed-by: Kevin Tian
> From: Andrew Cooper
> Sent: Thursday, May 11, 2023 3:34 AM
>
> Technically our helper post-dates all of these examples, but it's good cleanup
> nevertheless. None of these examples should be using fully locked
> test_and_set_bool() in the first place.
>
> No functional change.
>
> Signed-off
> From: Andrew Cooper
> Sent: Tuesday, May 16, 2023 10:54 PM
>
> MSR_ARCH_CAPS data is now included in featureset information.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Kevin Tian
> From: Marek Marczykowski-Górecki
> Sent: Saturday, September 17, 2022 10:51 AM
>
> Re-use rmrr= parameter handling code to handle common device reserved
> memory.
>
> Signed-off-by: Marek Marczykowski-Górecki
>
> ---
> Changes in v3:
> - make MAX_USER_RMRR_PAGES applicable only to user-configu
> From: Marczykowski, Marek
> Sent: Tuesday, September 27, 2022 7:54 AM
>
> On Fri, Sep 23, 2022 at 07:21:04AM +, Tian, Kevin wrote:
> > > From: Marek Marczykowski-Górecki
> > > Sent: Saturday, September 17, 2022 10:51 AM
> > >
> > > Re-us
> From: Jan Beulich
> Sent: Monday, October 10, 2022 6:25 PM
>
> With the addition of vmx_add_msr() calls to construct_vmcs() there are
> now cases where simply freeing the VMCS isn't enough: The MSR bitmap
> page as well as one of the MSR area ones (if it's the 2nd vmx_add_msr()
> which fails) m
501 - 585 of 585 matches
Mail list logo
