> From: Andrew Cooper
> Sent: Wednesday, September 9, 2020 5:59 PM
>
> They are currently named after the FSGSBASE instructions, but are not thin
> wrappers around said instructions, and therefore do not accurately reflect
> the
> logic they perform, especially when it comes to functioning safely
> From: Paul Durrant
> Sent: Tuesday, September 15, 2020 4:29 PM
>
> From: Paul Durrant
>
> This patch converts the VT-d code to use the new IOMMU page table
> allocator
> function. This allows all the free-ing code to be removed (since it is now
> handled by the general x86 code) which reduces
> From: Paul Durrant
> Sent: Tuesday, September 15, 2020 4:30 PM
>
> From: Paul Durrant
>
> At the moment iommu_map() and iommu_unmap() take a page order rather
> than a
> count, whereas iommu_iotlb_flush() takes a page count rather than an order.
> This patch makes them consistent with each ot
> From: Paul Durrant
> Sent: Tuesday, September 15, 2020 4:30 PM
>
> From: Paul Durrant
>
> Sharing of HAP tables is now VT-d specific so the operation is never defined
> for AMD IOMMU any more. There's also no need to pro-actively set
> vtd.pgd_maddr
> when using shared EPT as it is straightfo
> From: Tian, Kevin
> Sent: Thursday, September 17, 2020 3:20 PM
>
> > From: Paul Durrant
> > Sent: Tuesday, September 15, 2020 4:30 PM
> >
> > From: Paul Durrant
> >
> > Sharing of HAP tables is now VT-d specific so the operation is never define
> From: Paul Durrant
> Sent: Tuesday, September 15, 2020 4:30 PM
>
> From: Paul Durrant
>
> It's confusing and not consistent with the terminology introduced with
> 'dfn_t'.
> Just call them IOMMU page tables.
>
> Also remove a pointless check of the 'acpi_drhd_units' list in
> vtd_dump_page_
> From: Paul Durrant
> Sent: Tuesday, September 15, 2020 4:30 PM
>
> From: Paul Durrant
>
> The 'legacy' functions do implicit flushing so amend the callers to do the
> appropriate flushing.
>
> Unfortunately, because of the structure of the P2M code, we cannot remove
> the per-CPU 'iommu_dont
> From: Roger Pau Monne
> Sent: Wednesday, March 25, 2020 6:19 PM
>
> Check whether there's a valid interrupt in VM_EXIT_INTR_INFO in order
> to decide whether to update SVI in nvmx_update_apicv. If Ack on exit
> is not being used VM_EXIT_INTR_INFO won't have a valid interrupt and
> hence SVI sho
> From: Roger Pau Monne
> Sent: Wednesday, March 25, 2020 6:19 PM
>
> Updating SVI is required when an interrupt has been injected using the
> Ack on exit VMEXIT feature, so that the in service interrupt in the
> GUEST_INTR_STATUS matches the vector that is signaled in
> VM_EXIT_INTR_INFO.
>
> U
> From: Roger Pau Monne
> Sent: Wednesday, March 25, 2020 6:19 PM
>
> Force an update of the EOI exit bitmap in nvmx_update_apicv, because
> the one performed in vmx_intr_assist might not be reached if the
> interrupt is intercepted by nvmx_intr_intercept returning true.
>
> Extract the code to
> From: Roger Pau Monné
> Sent: Tuesday, March 24, 2020 8:19 PM
>
> On Tue, Mar 24, 2020 at 11:33:00AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monné
> > > Sent: Tuesday, March 24, 2020 7:23 PM
> > >
> > > On Tue, Mar 24, 2020 at 10:11:15AM
> From: Roger Pau Monné
> Sent: Thursday, March 26, 2020 5:20 PM
>
> On Thu, Mar 26, 2020 at 03:13:56AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne
> > > Sent: Wednesday, March 25, 2020 6:19 PM
> > >
> > > Updating SVI is requir
> From: Roger Pau Monné
> Sent: Thursday, March 26, 2020 5:22 PM
>
> On Thu, Mar 26, 2020 at 03:17:59AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne
> > > Sent: Wednesday, March 25, 2020 6:19 PM
> > >
> > > Force an update of the EOI exi
> From: Roger Pau Monne
> Sent: Thursday, March 26, 2020 11:27 PM
>
> Updating SVI is required when an interrupt has been injected using the
> Ack on exit VMEXIT feature, so that the in service interrupt in the
> GUEST_INTR_STATUS matches the vector that is signaled in
> VM_EXIT_INTR_INFO.
>
> U
> From: Roger Pau Monne
> Sent: Thursday, March 26, 2020 11:27 PM
>
> Force an update of the EOI exit bitmap in nvmx_update_apicv, because
> the one performed in vmx_intr_assist might not be reached if the
> interrupt is intercepted by nvmx_intr_intercept returning true.
>
> Extract the code to
> From: Jan Beulich
> Sent: Tuesday, March 24, 2020 8:37 PM
>
> If the hardware can handle accesses, we should allow it to do so. This
> way we can expose EFRO to HVM guests, and "all" that's left for exposing
> APERF/MPERF is to figure out how to handle writes to these MSRs. (Note
> that the lea
> From: Isaila Alexandru
> Sent: Tuesday, March 24, 2020 6:46 PM
>
>
> Hi Kevin and sorry for the long reply time,
>
> On 10.03.2020 04:04, sTian, Kevin wrote:
> >> From: Alexandru Stefan ISAILA
> >> Sent: Tuesday, March 3, 2020 8:23 PM
> >>
> >> At this moment a guest can call vmfunc to chan
> From: Alexandru Isaila
> Sent: Monday, March 30, 2020 2:55 PM
>
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
>
> The new xc_altp2m_set_visibility() solves this by making views invisible
> to vmfunc.
> T
> From: Roger Pau Monne
> Sent: Friday, April 17, 2020 7:30 PM
>
> The EPT page tables can be shared with the IOMMU as long as the page
> sizes supported by EPT are also supported by the IOMMU.
>
> Current code checks that both the IOMMU and EPT support the same page
> sizes, but this is not str
> From: Brendan Kerrigan
> Sent: Friday, April 17, 2020 9:36 PM
>
> From: Brendan Kerrigan
>
> The Intel graphics device records DMAR faults regardless
> of the Fault Process Disable bit being set. When this fault
Since this is an errata for specific generations, let's describe
this way instea
> From: Andrew Cooper
> Sent: Monday, April 20, 2020 10:59 PM
>
> This will cause all SYSCALL/SYSRET instructions to suffer #UD rather than
> following the MSR_{L,C}STAR pointers, allowing us to drop the star_enter()
> panic helper, allowing us to clean up the IST stacks in a subsequent patch.
>
> From: Jan Beulich
> Sent: Saturday, February 1, 2020 12:42 AM
>
> It's not needed there and introduces a needless, almost global
> dependency. Include the file (or in some cases just xen/err.h) where
> actually needed, or - in one case - simply forward-declare a struct. In
> microcode*.c take t
> From: Jan Beulich
> Sent: Thursday, February 6, 2020 9:31 PM
>
> Checking just the first and last page is not sufficient (and redundant
> for single-page regions). As we don't need to care about IA64 anymore,
> use an x86-specific function to get this done without looping over each
> individual
> From: Jan Beulich
> Sent: Thursday, February 6, 2020 9:31 PM
> To: xen-devel@lists.xenproject.org
> Cc: Tian, Kevin
> Subject: [PATCH 2/2] VT-d: adjust logging of RMRRs
>
> Consistently use [,] range representation, shrink leading double blanks
> to a single one, and
> From: Jan Beulich
> Sent: Thursday, February 6, 2020 11:35 PM
>
> The field looks to have been bogusly added by the patch introducing the
> struct (431685e8deb6 "VT-d: add command line option for extra rmrrs").
>
> Signed-off-by: Jan Beulich
>
Reviewed-by: Kevin Tian
__
> From: Jan Beulich
> Sent: Thursday, February 6, 2020 11:20 PM
>
> Both callers request the host P2M's default access, which can as well be
> done inside the function. While touching this anyway, make the "gfn"
> parameter type-safe as well.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin T
> From: Juergen Gross
> Sent: Tuesday, February 11, 2020 5:31 PM
>
> One of the main design goals of core scheduling is to avoid actions
> which are not directly related to the domain currently running on a
> given cpu or core. Live patching is one of those actions which are
> allowed taking plac
> From: Juergen Gross
> Sent: Thursday, February 13, 2020 8:55 PM
>
> Using for_each_domain() with out holding the domlist_read_lock is
> fragile, so add the lock in the keyhandlers it is missing.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Kevin Tian
__
> From: Roger Pau Monne
> Sent: Monday, February 17, 2020 7:46 PM
>
> Current implementation of nested VMX has a half baked handling of MSR
> bitmaps for the L1 VMM: it maps the L1 VMM provided MSR bitmap, but
> doesn't actually load it into the nested vmcs, and thus the nested
> guest vmcs ends
> From: Jan Beulich
> Sent: Thursday, February 27, 2020 7:15 PM
>
> First of all in commit d6573bc6e6b7 ("VT-d: check all of an RMRR for
> being E820-reserved") along with changing the function used, the enum-
> like value passed should have been changed too (to E820_*). Do so now.
> (Luckily the
> From: Jan Beulich
> Sent: Friday, February 28, 2020 8:25 PM
>
> A number of the command line controlled variables are x86-
> or even x86-HVM-specific. Don't have those variables elsewhere
> in the first place (in some cases replace them by a #define),
> and as a result also don't silently accep
> From: Jan Beulich
> Sent: Thursday, March 5, 2020 5:24 PM
>
> On 26.02.2020 12:33, Anthony PERARD wrote:
> > This is part of upgrading our build system and import more of Linux's
> > one.
> >
> > In Linux, subdir-y in Makefiles is only used to descend into
> > subdirectory when there are no obj
> From: Jan Beulich
> Sent: Monday, March 9, 2020 4:59 PM
>
> On 28.02.2020 13:12, Jan Beulich wrote:
> > The wider cluster mode APIC IDs aren't generally representable. Convert
> > the iommu_intremap variable into a tristate, allowing the AMD IOMMU
> > driver to signal this special restriction t
> From: Jan Beulich
> Sent: Monday, March 9, 2020 6:43 PM
>
> Provide a #define for all other cases.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Refine doc adjustment.
>
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1309,6 +1309,8 @@ boolean (e.g. `io
> From: Jan Beulich
> Sent: Monday, March 9, 2020 6:40 PM
>
> A number of the command line controlled variables are x86-
> or even x86-HVM-specific. Don't have those variables elsewhere
> in the first place (in some cases replace them by a #define),
> and as a result also don't silently accept su
> From: Alexandru Stefan ISAILA
> Sent: Tuesday, March 3, 2020 8:23 PM
>
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
I look forward to more elaboration of the motivation, especially for one
who doesn't t
> From: Jan Beulich
> Sent: Tuesday, March 3, 2020 6:17 PM
>
> Emulation requiring device model assistance uses a form of instruction
> re-execution, assuming that the second (and any further) pass takes
> exactly the same path. This is a valid assumption as far as use of CPU
ah, I was not aware
> From: Jan Beulich
> Sent: Monday, March 9, 2020 7:09 PM
>
> 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 guests coul
> From: Jan Beulich
> Sent: Monday, March 9, 2020 7:09 PM
>
> 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 guests coul
> From: Jan Beulich
> Sent: Tuesday, March 10, 2020 11:51 PM
>
> Drop #include-s not needed by the header itself as well as one include
> of the header which isn't needed. Put the one needed into the file
> actually requiring it.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
> From: Jan Beulich
> Sent: Tuesday, March 10, 2020 11:52 PM
>
> Drop #include-s not needed by the header itself, and add smaller scope
> ones instead. Put the ones needed into whichever other files actually
> need them.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
_
> From: Jan Beulich
> Sent: Tuesday, March 10, 2020 6:27 PM
>
> On 10.03.2020 04:43, Tian, Kevin wrote:
> >> From: Jan Beulich
> >> Sent: Monday, March 9, 2020 7:09 PM
> >>
> >> I'm happy to take better suggestions to replace the "f
> From: Jan Beulich
> Sent: Tuesday, March 10, 2020 6:31 PM
>
> On 10.03.2020 06:30, Tian, Kevin wrote:
> >> From: Jan Beulich
> >> Sent: Monday, March 9, 2020 7:09 PM
> >>
> >> Containing still in flight DMA was introduced to work around certain
> From: Paul Durrant
> Sent: Wednesday, March 11, 2020 12:05 AM
>
[...]
>
> >
> > > However, is a really saying that things will break if any of the
> > > PTEs has their present bit clear?
> >
> > Well, you said that read faults are fatal (to the host). Reads will,
> > for any address with an un
> From: Andrew Cooper
> Sent: Thursday, March 12, 2020 2:35 AM
>
> c/s c47984aabead "nvmx: implement support for MSR bitmaps" introduced a
> use of
> map_domain_page() which may get used in the middle of context switch.
>
> This is not safe, and causes Xen to deadlock on the mapcache lock:
>
>
> From: Paul Durrant
> Sent: Friday, March 13, 2020 5:26 PM
>
> > -Original Message-
> > From: Tian, Kevin
> > Sent: 13 March 2020 03:23
> > To: p...@xen.org; 'Jan Beulich'
> > Cc: xen-devel@lists.xenproject.org; 'Andrew Cooper&#
> From: Paul Durrant
> Sent: Friday, March 13, 2020 5:26 PM
>
> > -Original Message-
> > From: Jan Beulich
> > Sent: 13 March 2020 08:10
> > To: Tian, Kevin
> > Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Paul Durrant
> &
> From: Andrew Cooper
> Sent: Saturday, March 14, 2020 12:03 AM
>
> On 12/03/2020 23:56, osstest service owner wrote:
> > branch xen-unstable
> > xenbranch xen-unstable
> > job test-amd64-amd64-qemuu-nested-intel
> > testid debian-hvm-install/l1/l2
> >
> > Tree: linux git://git.kernel.org/pub/scm
> From: Roger Pau Monné
> Sent: Monday, March 23, 2020 10:49 PM
>
> On Mon, Mar 23, 2020 at 09:09:59AM +0100, Jan Beulich wrote:
> > On 20.03.2020 20:07, Roger Pau Monne wrote:
> > > This reverts commit f96e1469ad06b61796c60193daaeb9f8a96d7458.
> > >
> > > The commit is wrong, as the whole point
> From: Roger Pau Monne
> Sent: Saturday, March 21, 2020 3:08 AM
>
> The current usage of nvmx_update_apicv is not clear: it is deeply
> intertwined with the Ack interrupt on exit VMEXIT control.
>
> The code in nvmx_update_apicv should update the SVI (in service interrupt)
> field of the guest
> From: Roger Pau Monne
> Sent: Saturday, March 21, 2020 3:08 AM
>
> Current code in nvmx_update_apicv set the guest interrupt status field
> but doesn't update the exit bitmap, which can cause issues of lost
> interrupts on the L1 hypervisor if vmx_intr_assist gets
> short-circuited by nvmx_intr
> From: Jan Beulich
> Sent: Tuesday, March 24, 2020 4:10 PM
>
> On 24.03.2020 06:41, Tian, Kevin wrote:
> >> From: Roger Pau Monné
> >> Sent: Monday, March 23, 2020 10:49 PM
> >>
> >> On Mon, Mar 23, 2020 at 09:09:59AM +0100, Jan Beulich wrote:
> From: Roger Pau Monné
> Sent: Tuesday, March 24, 2020 5:51 PM
>
> On Tue, Mar 24, 2020 at 06:03:28AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne
> > > Sent: Saturday, March 21, 2020 3:08 AM
> > >
> > > The current usage
> From: Roger Pau Monné
> Sent: Tuesday, March 24, 2020 5:59 PM
>
> On Tue, Mar 24, 2020 at 06:22:43AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne
> > > Sent: Saturday, March 21, 2020 3:08 AM
> > >
> > > Current code in nvmx_update_apic
> From: Roger Pau Monné
> Sent: Tuesday, March 24, 2020 6:47 PM
>
> On Tue, Mar 24, 2020 at 08:49:27AM +, Tian, Kevin wrote:
> > > From: Jan Beulich
> > > Sent: Tuesday, March 24, 2020 4:10 PM
> > >
> > > On 24.03.2020 06:41, Tian, Kevin wrot
> From: Roger Pau Monné
> Sent: Tuesday, March 24, 2020 7:23 PM
>
> On Tue, Mar 24, 2020 at 10:11:15AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monné
> > > Sent: Tuesday, March 24, 2020 5:51 PM
> > >
> > > On Tue, Mar 24, 2020 at 06:03:28AM
> From: Jan Beulich
> Sent: Tuesday, October 20, 2020 4:10 PM
>
> On 19.10.2020 18:12, Andrew Cooper wrote:
> > On 19/10/2020 10:09, Jan Beulich wrote:
> >> On 16.10.2020 17:38, Andrew Cooper wrote:
> >>> On 15/10/2020 09:01, Jan Beulich wrote:
> On 14.10.2020 15:57, Andrew Cooper wrote:
> >
> From: Jan Beulich
> Sent: Tuesday, October 20, 2020 9:53 PM
>
> While the flush coalescing optimization has been helping the non-shared
> case, it has actually lead to double flushes in the shared case (which
> ought to be the more common one nowadays at least): Once from
> *_set_entry() and a
> From: Jan Beulich
> Sent: Friday, December 20, 2019 11:02 PM
>
> On 20.12.2019 15:58, George Dunlap wrote:
> > On 12/20/19 2:41 PM, Jan Beulich wrote:
> >> On 20.12.2019 15:26, George Dunlap wrote:
> >>> On 12/20/19 2:21 PM, Jan Beulich wrote:
> In ept_p2m_type_to_flags() passing in type a
> From: Roger Pau Monné
> Sent: Tuesday, December 31, 2019 11:30 PM
>
> On Mon, Dec 30, 2019 at 08:19:23PM +, osstest service owner wrote:
> > flight 145393 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/145393/
> >
> > Regressions :-(
> >
> > Tests which did no
> From: Jan Beulich
> Sent: Tuesday, January 7, 2020 12:39 AM
>
> If the hardware can handle accesses, we should allow it to do so. This
> way we can expose EFRO to HVM guests, and "all" that's left for exposing
> APERF/MPERF is to figure out how to handle writes to these MSRs. (Note
> that the l
> From: Jan Beulich
> Sent: Tuesday, January 7, 2020 3:38 PM
>
> When passed a non-NULL pdev, the function does an owner check when it
> finds an already existing context mapping. Bridges, however, don't get
> passed through to guests, and hence their owner is always going to be
> Dom0, leading t
> From: Jan Beulich
> Sent: Tuesday, January 7, 2020 3:38 PM
>
> Add missing newlines, use %pd, and drop exclamation marks.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://list
> From: Jan Beulich
> Sent: Tuesday, January 7, 2020 7:56 PM
>
> Hence it's pointless for it to return an error indicator, and it's even
> less useful for it to be __must_check. This is a result of commit
> e8afe1124cc1 ("iommu: elide flushing for higher order map/unmap
> operations") moving the
> From: Andrew Cooper
> Sent: Tuesday, January 7, 2020 8:25 PM
>
> No need to use 4-byte integers to store two bits of information.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
ht
> From: Roger Pau Monne
> Sent: Wednesday, January 8, 2020 6:39 PM
>
> When doing a virtual vmexit (ie: a vmexit handled by the L1 VMM)
> interrupts shouldn't be injected using the virtual interrupt delivery
> mechanism, and instead should be signaled in the vmcs using the exit
> reason and the i
> From: Alexandru Stefan ISAILA
> Sent: Wednesday, January 8, 2020 10:09 PM
>
> No functional changes.
>
> Requested-by: Jan Beulich
> Signed-off-by: Alexandru Isaila
> Reviewed-by: Jan Beulich
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xe
> From: Roger Pau Monne
> Sent: Wednesday, January 8, 2020 8:32 PM
>
> Current implementation of nested VMX has a half baked handling of MSR
> bitmaps for the L1 VMM: it maps the L1 VMM provided MSR bitmap, but
> doesn't actually load it into the nested vmcs, and thus the nested
> guest vmcs ends
> From: Jan Beulich
> Sent: Monday, January 20, 2020 4:33 PM
>
> On 19.01.2020 03:44, Tian, Kevin wrote:
> >> From: Jan Beulich
> >> Sent: Tuesday, January 7, 2020 12:39 AM
> >>
> >> If the hardware can handle accesses, we should allow it to do so
> From: Roger Pau Monné
> Sent: Monday, January 20, 2020 6:19 PM
>
> On Sun, Jan 19, 2020 at 04:15:04AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne
> > > Sent: Wednesday, January 8, 2020 6:39 PM
> > >
> > > When doing a vi
> From: Jan Beulich
> Sent: Monday, January 20, 2020 11:42 PM
>
> When passed a non-NULL pdev, the function does an owner check when it
> finds an already existing context mapping. Bridges, however, don't get
> passed through to guests, and hence their owner is always going to be
> Dom0, leading
> From: Roger Pau Monné
> Sent: Wednesday, January 22, 2020 12:47 AM
>
> On Tue, Jan 21, 2020 at 03:34:13AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monné
> > > Sent: Monday, January 20, 2020 6:19 PM
> > >
> > > On Sun, Jan 19, 2020 at 04:
> From: Paul Durrant
> Sent: Tuesday, January 21, 2020 8:00 PM
>
> Use mfn_t rather than unsigned long and change previous tests against 0 to
> tests against INVALID_MFN (also introducing initialization to that value).
>
> Signed-off-by: Paul Durrant
Reviewed-by: Kevin Tian
_
> From: Paul Durrant
> Sent: Tuesday, January 21, 2020 8:00 PM
>
> vmx_alloc_vlapic_mapping() currently contains some very odd looking code
> that allocates a MEMF_no_owner domheap page and then shares with the
> guest
> as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
>
> From: Jan Beulich
> Sent: Saturday, January 18, 2020 12:36 AM
>
> The code is quite a bit easier to read and to reason about this way,
> I think.
>
> In ept_set_entry() additionally change the function's return value in
> the MAP_FAILED case to -ENOMEM; -ENOENT would be applicable only when
>
> From: Jan Beulich
> Sent: Wednesday, January 22, 2020 10:41 PM
>
> All callers set the respective fields in the entry being updated before
> the call.
>
> Take the opportunity and also constify the first parameter as well as
> make a few style adjustments.
>
> Signed-off-by: Jan Beulich
Rev
> From: Juergen Gross
> Sent: Tuesday, January 21, 2020 4:43 PM
>
> Move the parameter related definitions from init.h into a new header
> file param.h. This will avoid include hell when new dependencies are
> added to parameter definitions.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Kevin
> From: Roger Pau Monné
> Sent: Thursday, January 23, 2020 8:32 PM
>
> On Tue, Jan 21, 2020 at 03:34:13AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monné
> > > Sent: Monday, January 20, 2020 6:19 PM
> > >
> > > On Sun, Jan 19, 2020 at 04:
> From: Roger Pau Monne
> Sent: Wednesday, January 29, 2020 10:45 PM
>
> Current implementation of nested VMX has a half baked handling of MSR
> bitmaps for the L1 VMM: it maps the L1 VMM provided MSR bitmap, but
> doesn't actually load it into the nested vmcs, and thus the nested
> guest vmcs en
> From: Roger Pau Monne
> Sent: Wednesday, January 29, 2020 10:45 PM
>
> Nested VMX doesn't expose support for
> SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE,
> SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or
> SECONDARY_EXEC_APIC_REGISTER_VIRT, and hence the x2APIC MSRs should
> always be trapped in the nested
> From: Paul Durrant
> Sent: Thursday, January 30, 2020 1:10 AM
>
> ... to domain_relinquish_resources().
>
> The teardown code frees the APICv page. This does not need to be done late
> so do it in domain_relinquish_resources() rather than domain_destroy().
>
> Signed-off-by: Paul Durrant
Re
> From: Paul Durrant
> Sent: Thursday, January 30, 2020 10:58 PM
>
> vmx_alloc_vlapic_mapping() currently contains some very odd looking code
> that allocates a MEMF_no_owner domheap page and then shares with the
> guest
> as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
> From: Roger Pau Monné
> Sent: Monday, February 3, 2020 7:56 PM
>
> On Mon, Feb 03, 2020 at 07:24:04AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monné
> > > Sent: Thursday, January 23, 2020 8:32 PM
> > >
> > > On Tue, Jan 21, 2020 at 03:
> From: Roger Pau Monne
> Sent: Monday, February 3, 2020 8:19 PM
>
> When doing a virtual vmexit (ie: a vmexit handled by the L1 VMM)
> interrupts shouldn't be injected using the virtual interrupt delivery
> mechanism unless the Ack on exit vmexit control bit isn't set in the
> nested vmcs.
>
>
> From: Roger Pau Monne
> Sent: Monday, February 3, 2020 8:19 PM
>
> When VM_EXIT_ACK_INTR_ON_EXIT is set in the vmexit control vmcs
set->cleared
> register the bit 31 of VM_EXIT_INTR_INFO must be 0, in order to denote
> that the field doesn't contain any interrupt information. This is not
> cu
> From: Roger Pau Monne
> Sent: Monday, February 3, 2020 8:19 PM
>
> If virtual interrupt delivery is used to inject the interrupt to the
> guest the interrupt window shouldn't be enabled, as the interrupt is
> already injected using the GUEST_INTR_STATUS vmcs field.
>
> Reported-by: Kevin Tian
> From: Roger Pau Monne
> Sent: Tuesday, February 4, 2020 1:37 AM
>
> Current implementation of nested VMX has a half baked handling of MSR
> bitmaps for the L1 VMM: it maps the L1 VMM provided MSR bitmap, but
> doesn't actually load it into the nested vmcs, and thus the nested
> guest vmcs ends
> From: Jan Beulich
> Sent: Tuesday, February 4, 2020 5:50 PM
>
> On 04.02.2020 10:23, Roger Pau Monné wrote:
> > On Tue, Feb 04, 2020 at 01:35:05AM +, Tian, Kevin wrote:
> >>> From: Roger Pau Monne
> >>> Sent: Monday, February 3, 2020 8:19 PM
>
> From: Roger Pau Monné
> Sent: Friday, January 15, 2021 1:21 AM
>
> On Thu, Jan 14, 2021 at 02:41:29PM +0100, Jan Beulich wrote:
> > On 14.01.2021 13:33, Roger Pau Monné wrote:
> > > On Thu, Jan 14, 2021 at 12:45:27PM +0100, Jan Beulich wrote:
> > >> On 14.01.2021 11:22, Roger Pau Monné wrote:
>
> From: Jan Beulich
> Sent: Friday, January 29, 2021 7:45 PM
>
> There are three noteworthy drawbacks:
> 1) The intercepts we need to enable here are CPL-independent, i.e. we
>now have to emulate certain instructions for ring 0.
> 2) On VMX there's no intercept for SMSW, so the emulation isn'
> From: Julien Grall
> Sent: Tuesday, February 9, 2021 11:28 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 root
> page-table (i.e. hd->arch.pg_maddr) will not be cleared.
It's t
> From: Jan Beulich
> Sent: Wednesday, July 15, 2020 6:04 PM
>
> Instead of checking inside the hook whether any non-coherent IOMMUs are
> present, simply install the hook only when this is the case.
>
> To prove that there are no other references to the now dynamically
> updated ops structure (
> From: Jan Beulich
> Sent: Wednesday, July 15, 2020 6:04 PM
>
> For full pages this is (meant to be) more efficient. Also change the
> type and reduce the scope of the involved local variable.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/drivers/passthrough/vtd/iomm
> From: Roger Pau Monne
> Sent: Thursday, July 30, 2020 10:03 PM
>
> Remove the unneeded else branch, which allows to reduce the
> indentation of a larger block of code, while making the flow of the
> function more obvious.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
> From: Roger Pau Monne
> Sent: Wednesday, August 12, 2020 8:47 PM
arameter
>
> Change the last parameter of the update_eoi_exit_bitmap helper to be a
> set/clear boolean instead of a triggering field. This is already
> inline with how the function is implemented, and will allow deciding
> whethe
> From: Paul Durrant
> Sent: Tuesday, August 4, 2020 9:42 PM
>
> From: Paul Durrant
>
> ... from those specific to VT-d or AMD IOMMU, and put the latter in a union.
>
> There is no functional change in this patch, although the initialization of
> the 'mapped_rmrrs' list occurs slightly later i
> From: Paul Durrant
> Sent: Tuesday, August 4, 2020 9:42 PM
>
> From: Paul Durrant
>
> This patch converts the VT-d code to use the new IOMMU page table
> allocator
> function. This allows all the free-ing code to be removed (since it is now
> handled by the general x86 code) which reduces TLB
> From: Paul Durrant
> Sent: Tuesday, August 4, 2020 9:42 PM
>
> From: Paul Durrant
>
> This patch adds a full I/O TLB flush to the error paths of iommu_map() and
> iommu_unmap().
>
> Without this change callers need constructs such as:
>
> rc = iommu_map/unmap(...)
> err = iommu_flush(...)
>
> From: Jan Beulich
> Sent: Thursday, August 6, 2020 5:57 PM
>
> On 04.08.2020 15:42, Paul Durrant wrote:
> > From: Paul Durrant
> >
> > At the moment iommu_map() and iommu_unmap() take a page order but
> not a
> > count, whereas iommu_iotlb_flush() takes a count but not a page order.
> > This p
> From: Paul Durrant
> Sent: Tuesday, August 4, 2020 9:42 PM
>
> From: Paul Durrant
>
> Sharing of HAP tables is now VT-d specific so the operation is never defined
> for AMD IOMMU any more. There's also no need to pro-actively set
> vtd.pgd_maddr
> when using shared EPT as it is straightforwar
301 - 400 of 585 matches
Mail list logo
