> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 4, 2018 4:33 PM
> >
> > bus address is commonly used along with physical/virtual address, to
> > represent different views between devices and CPU. From that angle
> > I think BFN is a clear term in this context. btw it is no
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 4, 2018 5:08 PM
>
> >>> On 04.09.18 at 10:49, wrote:
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 04 September 2018 09:47
> >> To: Kevin Tian
> >> Cc: Suravee Suthikulpanit
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, September 5, 2018 2:49 PM
>
> >>> On 05.09.18 at 02:42, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Tuesday, September 4, 2018 5:08 PM
> >>
> >> >>> On 04.09.18 at 10:49, wrote:
> >> >> -Original Mess
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Thursday, September 6, 2018 10:54 PM
>
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 06 September 2018 14:13
> > To: Paul Durrant
> > Cc: Suravee Suthikulpanit ; Julien Grall
> > ; Kevin Tian
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Friday, September 7, 2018 4:13 PM
>
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 07 September 2018 07:24
> > To: Paul Durrant ; Kevin Tian
> >
> > Cc: Suravee Suthikulpanit ; Julien Grall
>
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 10, 2018 9:59 PM
>
> For one it is quite pointless to iterate over all pIRQ-s the domain has
> when just one is being adjusted. Introduce hvm_migrate_pirq().
it's migrate_pirq being introduced here.
>
> Additionally it is
> From: Jan Beulich
> Sent: Friday, September 7, 2018 7:01 PM
>
> >>> On 23.08.18 at 11:47, wrote:
> > This patch adds an iommu_op to allow the domain IOMMU reserved
> ranges to be
> > queried by the guest.
> >
> > NOTE: The number of reserved ranges is determined by system firmware,
> in
> >
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 11, 2018 5:48 PM
>
> >>> On 11.09.18 at 11:39, wrote:
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 07 September 2018 12:20
> >> To: Paul Durrant
> >> Cc: Julien Grall ; Andr
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 11, 2018 9:16 PM
>
> Since strictly speaking it is incorrect for guest_walk_tables() to read
> L3 entries during PAE page walks, try to overcome this where possible by
can you elaborate? why it's incorrect to read L3 entrie
> From: Paul Durrant
> Sent: Wednesday, September 12, 2018 4:02 PM
>
>
> > In order to avoid shooting down all pre-existing RAM mappings - is
> > there no way the page table entries could be marked to identify
> > their origin?
> >
>
> I don't know whether that is possible; I'll have to find spe
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Wednesday, September 12, 2018 7:30 PM
>
> This patch removes the implicit domain_crash() from iommu_map(),
> unmap_page() and iommu_iotlb_flush() and turns them into
> straightforward
> wrappers that check the existence of the relevant
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Wednesday, September 12, 2018 7:30 PM
>
> This patch adds a new method to the VT-d IOMMU implementation to find
> the
> MFN currently mapped by the specified DFN along with a wrapper function
> in generic IOMMU code to call the implemen
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 13, 2018 4:55 PM
>
> >>> On 13.09.18 at 08:30, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Tuesday, September 11, 2018 9:16 PM
> >>
> >> Since strictly speaking it is incorrect for guest_walk_table
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Thursday, September 13, 2018 11:21 PM
>
> ...meaning 'device DMA frame number' i.e. a frame number mapped in the
> IOMMU
> (rather than the MMU) and hence used for DMA address translation.
>
> This patch is a largely cosmetic change th
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Thursday, September 13, 2018 11:21 PM
>
> ...in intel_iommu_unmap_page().
>
> This patch also includes some non-functional modifications in
> intel_iommu_map_page().
>
> Signed-off-by: Paul Durrant
Acked-by: Kevin Tian
___
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Thursday, September 13, 2018 11:21 PM
>
> This patch adds a new method to the VT-d IOMMU implementation to find
> the
> MFN currently mapped by the specified DFN along with a wrapper function
> in generic IOMMU code to call the implemen
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, September 14, 2018 9:59 PM
>
> Or else it can lead to freezes when enabling the iommu on certain
> Intel hardware:
>
> [...]
> (XEN) ELF: addresses:
> (XEN) virt_base= 0x8000
> (XEN) elf_paddr_offset
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Thursday, September 20, 2018 10:12 PM
>
> Commit 43d1622b "vtd: add lookup_page method to iommu_ops" added a
> lookup method in to the VT-d IOMMU implementation. In some cases (such
> as
> when shared EPT is in operation) that function
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, September 21, 2018 11:21 PM
>
> And just rely on arch_iommu_hwdom_init to setup the correct inclusive
> mappings as it's done for Intel.
>
> AMD has code in amd_iommu_hwdom_init to setup inclusive mappings up
> to
> max_pdx, re
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Tuesday, September 25, 2018 7:03 PM
>
> Move p2m_{get/set}_suppress_ve() to p2m.c, replace incorrect
> ASSERT() in p2m-pt.c (since a guest can run in shadow mode even on
> a system with virt exceptions, which would trigger the ASSE
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, October 2, 2018 6:39 PM
>
> >>> On 25.09.18 at 16:25, wrote:
> > 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
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, October 5, 2018 7:32 PM
>
> A few pieces of the handling here are (no longer?) vendor specific, and
> hence there's no point in replicating the code. Make sure not otherwise
> pre-filled fields of struct hvm_hw_cpu instances are zero f
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, October 6, 2018 1:02 AM
>
> When using shadow paging, EFER.NX is a Xen controlled bit, and is required
> by
> the shadow pagefault handler to distinguish instruction fetches from data
> accesses.
>
> This can be observed b
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, October 11, 2018 4:28 PM
>
> On Tue, Oct 09, 2018 at 03:57:08PM +0100, Wei Liu wrote:
> > Commit 2916951c1 ("mm / iommu: include need_iommu() test in
> > iommu_use_hap_pt()") included need_iommu() in iommu_use_hap_pt
> and
> > 91d4eca7
+Chao to help take a look.
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, October 12, 2018 5:33 PM
> To: xen-devel
> Cc: Andrew Cooper ; Wei Liu
> ; Nakajima, Jun ; Tian,
> Kevin
> Subject: [PATCH RFC] VMX: fix vmx_han
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, January 30, 2018 12:11 AM
>
> This is more vestigial rementants of PVHv1.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.x
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, February 5, 2018 7:17 PM
>
> The use of __LINE__ in a printk() is problematic for livepatching, as it
> causes unnecessary binary differences.
>
> Furthermore, diagnostic information around calls is inconsistent and
> occasi
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Monday, February 12, 2018 6:47 PM
>
> The idea of a paravirtual IOMMU interface was last discussed on xen-devel
> more than two years ago and narrowed down on a draft specification [1].
> There was also an RFC patch series posted with a
> From: Paul Durrant
> Sent: Monday, February 12, 2018 6:47 PM
>
> 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 so
> From: Paul Durrant
> Sent: Monday, February 12, 2018 6:47 PM
>
> Certain areas of memory, such as RMRRs, must be mapped 1:1
> (i.e. BFN == MFN) through the IOMMU.
>
> This patch adds an iommu_op to allow these ranges to be queried.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Jan Beulich
> Cc
> From: Paul Durrant
> Sent: Monday, February 12, 2018 6:47 PM
>
> This patch adds iommu_ops to allow a domain with control_iommu
> privilege
> to map and unmap pages from any guest over which it has mapping
> privilege
> in the IOMMU.
> These operations implicitly disable IOTLB flushing so that t
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, February 22, 2018 5:50 PM
>
> >>> On 22.02.18 at 10:44, wrote:
> > On Wed, Oct 11, 2017 at 05:27:05AM -0600, Jan Beulich wrote:
> >> >>> On 11.10.17 at 05:03, wrote:
> >> > --- a/xen/drivers/passthrough/vtd/iommu.c
> >> > +++ b/xen
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Friday, February 16, 2018 6:22 PM
>
> The emulation layers of Xen lack PCID support, and as we only offer
> PCID to HAP guests, all writes to CR3 are handled by hardware,
> except when introspection is involved. Consequently, tryin
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, February 20, 2018 4:57 PM
>
> There a bunch of bits in CR4 that should be allowed to be set directly
> by the guest without requiring Xen intervention, currently this is
> already done by passing through guest writes into the C
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, February 20, 2018 4:57 PM
>
> At the moment this is currently set at VMC{S/B} creation and not changed,
> but further patches are going to change the CR4 mask at runtime.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Kevin
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: Wednesday, February 21, 2018 10:03 PM
>
> The current prototype is slightly confusing because it takes a virtual
> address and a physical frame (not address!). Switching to MFN will improve
> safety and reduce the chance to mistakenly inve
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: Wednesday, February 21, 2018 10:03 PM
>
> Most of the users of page_to_mfn and mfn_to_page are either overriding
> the macros to make them work with mfn_t or use mfn_x/_mfn because the
> rest of the function use mfn_t.
>
> So make page_to
> From: Wei Liu
> Sent: Thursday, February 22, 2018 5:47 AM
>
> Hi all
>
> At some point I would like to make CONFIG_HVM and CONFIG_PV work.
> The
> passthrough code is one of the road blocks for that work.
Can you elaborate the motivation of this change? why does someone
want to disable HVM or
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, February 13, 2018 5:23 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 13 February 2018 06:43
> > To: Paul Durrant ; xen-
> de...@
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, February 13, 2018 5:25 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 13 February 2018 06:52
> > To: Paul Durrant ; xen-
> de...@
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, February 13, 2018 5:56 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 13 February 2018 06:56
> > To: Paul Durrant ; xen-
> de...@
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Friday, February 23, 2018 6:18 PM
>
> On Fri, Feb 23, 2018 at 04:56:38AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne [mailto:roger@citrix.com]
> > > Sent: Tuesday, February 20, 2018 4:57 P
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Friday, February 23, 2018 3:32 PM
>
> On 02/23/2018 09:29 AM, Razvan Cojocaru wrote:
> > Lacking PCID support in the emulation layer creates two different way of
> > handling the NOFLUSH being set: one is in hardware, and this happ
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Friday, February 23, 2018 5:41 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 23 February 2018 05:17
> > To: Paul Durrant ; xen-
> de...@lists.xenpr
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Friday, February 23, 2018 5:35 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 23 February 2018 05:36
> > To: Paul Durrant ; xen-
> de...@lists.xenpr
> From: Gao, Chao
> Sent: Saturday, February 24, 2018 9:51 AM
>
> On Mon, Feb 12, 2018 at 02:54:02PM +, Roger Pau Monné wrote:
> >On Fri, Nov 17, 2017 at 02:22:25PM +0800, Chao Gao wrote:
> >> When irq remapping is enabled, IOAPIC Redirection Entry may be in
> remapping
> >> format. If that, g
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, February 23, 2018 4:37 PM
>
> ... for non-existent MSRs: wrmsr_hypervisor_regs()'s comment clearly
> says that the function returns 0 for unrecognized MSRs, so
> {svm,vmx}_msr_write_intercept() should not convert this into success. We
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Saturday, February 24, 2018 12:08 AM
>
> On Fri, Feb 23, 2018 at 05:12:05AM +, Tian, Kevin wrote:
> > > From: Wei Liu
> > > Sent: Thursday, February 22, 2018 5:47 AM
> > >
> > > Hi al
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Monday, February 26, 2018 5:57 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 24 February 2018 02:57
> > To: Paul Durrant ; xen-
> de...@lists.xenpr
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Monday, February 26, 2018 6:05 PM
>
> There a bunch of bits in CR4 that should be allowed to be set directly
> by the guest without requiring Xen intervention, currently this is
> already done by passing through guest writes into the CR
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, February 27, 2018 1:35 AM
>
> The default case of vmx_msr_write_intercept() in particular is very tangled.
>
> First of all, fold long_mode_do_msr_{read,write}() into their callers. These
> functions were split out in the
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, February 27, 2018 1:35 AM
>
> Dispatch from the guest_{rd,wr}msr() functions, after confirming that the
> domain is configured to use viridian. This allows for simplifiction of the
> viridian helpers as they don't need to c
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, February 27, 2018 1:35 AM
>
> Dispatch from the guest_{rd,wr}msr() functions, after falling through from
> the
> !is_viridian_domain() case.
>
> Rename {rd,wr}msr_hypervisor_regs() to guest_{rd,wr}msr_xen() for
> consistenc
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Monday, February 26, 2018 5:57 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 24 February 2018 02:57
> > To: Paul Durrant ; xen-
> de...@lists.xenpr
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, February 27, 2018 3:11 AM
>
> On 26/02/18 11:25, Jan Beulich wrote:
> On 20.02.18 at 12:58, wrote:
> >> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the
> value in
> >> MSR_TSC_AUX, irrespective of
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, February 27, 2018 5:33 PM
>
> > -Original Message-
> [snip]
> > > I'll define some terms to try to avoid confusing...
> > >
> > > - where the IOMMU code in Xen maintains a map such that BFN == MFN,
> > > let’s call this
> From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
> Sent: Wednesday, October 24, 2018 5:19 PM
>
> The may_defer var was left with the older bool_t type. This patch
> changes the type to bool.
>
> Signed-off-by: Alexandru Isaila
Reviewed-by: Kevin Tian
__
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, October 25, 2018 5:46 PM
>
> >>> On 19.10.18 at 16:30, wrote:
> > On Fri, Oct 12, 2018 at 03:32:59AM -0600, Jan Beulich wrote:
> >>In commit 303066fdb1e ("VMX: fix interaction of APIC-V and Viridian
> >>emulation") I screwed up quit
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, October 25, 2018 9:58 PM
>
> >>> On 25.10.18 at 15:02, wrote:
> > On 25/10/18 13:51, Jan Beulich wrote:
> > On 15.10.18 at 14:06, wrote:
> >>> From the debugging, we see that PPR/IRR/ISR appear to retain their
> state
> >>> acr
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, October 25, 2018 11:37 PM
>
> This is a stopgap solution until the toolstack side of initialisation can be
> sorted out, but it does result in the nvmx_vcpu_in_vmx() predicate working
> correctly even when nested virt hasn'
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, October 25, 2018 11:39 PM
>
> Now that nvmx_handle_vmx_insn() performs all VT-x instruction checks,
> there is
> no need for redundant checking in vmx_inst_check_privilege(). Remove it,
> and
> take out the vmxon_check boo
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, October 25, 2018 11:39 PM
>
> Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, October 25, 2018 11:39 PM
>
> This is very dangerous from a security point of view, because a missing
> entry
> will cause L2's action to be interpreted as L1's action.
>
> Signed-off-by: Andrew Cooper
Acked-by: Kevin Ti
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, October 15, 2018 6:36 PM
>
> Reusing debugreg[5] for the PV emulated IO breakpoint information is
> confusing
> to read. Instead, introduce a dr7_emul field in pv_vcpu for the pupose.
>
> With the PV emulation out of the wa
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Friday, October 12, 2018 11:28 PM
>
> As a convenient helper function and refactor the code to use it.
>
> No functional change.
>
> Signed-off-by: Sergey Dyasli
since vmcx is hvm abstracted term, what about using this
helper in s
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Friday, October 12, 2018 11:28 PM
>
> Calling vmfail_valid() is correct only if vvmcx is valid. Modify
> functions to use vmfail() instead which performs the necessary check.
>
> Signed-off-by: Sergey Dyasli
Acked-by: Kevin Tian .
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Friday, October 12, 2018 11:28 PM
>
> And make nvmx_handle_vmptrld() return the new errno in case the
> provided
> address is the same as vmxon region address.
>
> While at it, correct the return value for not-4KB-aligned case.
>
>
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Friday, October 12, 2018 11:28 PM
>
> And make nvmx_handle_vmclear() return the new errno in case the
> provided
> address is the same as vmxon region address.
>
> While at it, correct the return value for not-4KB-aligned case and fo
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Friday, October 12, 2018 11:28 PM
>
> The size of Xen's virtual vmcs region is 4096 bytes. Correctly report
> it to the guest in case when VMCS shadowing is not available instead of
> providing H/W value (which is usually smaller).
w
> From: Tian, Kevin
> Sent: Tuesday, October 30, 2018 3:00 PM
>
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Thursday, October 25, 2018 9:58 PM
> >
> > >>> On 25.10.18 at 15:02, wrote:
> > > On 25/10/18 13:51, Jan Beulich wrote:
&
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, October 30, 2018 8:41 PM
>
> On 30/10/2018 07:41, Tian, Kevin wrote:
> >> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> >> Sent: Friday, October 12, 2018 11:28 PM
> >>
&
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, October 30, 2018 8:36 PM
>
> On 30/10/2018 08:06, Tian, Kevin wrote:
> >> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> >> Sent: Friday, October 12, 2018 11:28 PM
> >>
> &
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Wednesday, October 31, 2018 11:22 PM
>
> ...and re-name them to iommu_map/unmap() since they no longer
> necessarily
> operate on a single page.
>
> The P2M code currently contains many loops to deal with the fact that,
> while it may
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, November 6, 2018 8:08 PM
>
> As a convenient helper function and refactor the code to use it.
>
> No functional change.
>
> Signed-off-by: Sergey Dyasli
Reviewed-by: Kevin Tian
__
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, November 6, 2018 8:08 PM
>
> And use it in nvmx_handle_invept() and nvmx_handle_invvpid().
>
> Signed-off-by: Sergey Dyasli
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, November 6, 2018 8:08 PM
>
> Calling vmfail_valid() is correct only if vvmcx is valid. Modify
> functions to use vmfail() instead which performs the necessary check.
>
> While at it, add ASSERTs into vmfail_valid/invalid() t
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, November 6, 2018 8:08 PM
>
> 1. Add VMX_INSN_VMCLEAR_WITH_VMXON_PTR errno and add the
> appropriate
>check to the function.
>
> 2. Correct the return value for not-4KB-aligned case and for invalid
>physaddr (when hvm
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, November 6, 2018 8:08 PM
>
> The size of Xen's virtual vmcs region is 4096 bytes (see comment about
> Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). Correctly
> report
> it to the guest in case when VMCS shadowing is
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, November 9, 2018 12:16 AM
>
> There's no need to go through an extra level of indirection. In order to
> limit code churn, call sites using struct domain_iommu's platform_ops
> don't get touched here, however.
>
> Signed-off-by: Jan B
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, November 6, 2018 8:08 PM
>
> Currently Xen tries to map bitmaps during emulation of vmptrld and
> vmwrite. This is wrong: a guest can store arbitrary values in those
> fields.
>
> Make bitmaps mapping happen only during a ne
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, November 9, 2018 10:42 PM
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://l
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Sunday, November 11, 2018 10:07 PM
>
> This patch is a pre-requisite for fixing the logdirty VGA issue
> (display freezes when switching to a new altp2m view early in a
> domain's lifetime), but sent separately for easier review.
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Sunday, November 11, 2018 10:07 PM
>
> 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: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Wednesday, November 14, 2018 3:33 PM
>
> On 11/14/18 7:55 AM, Tian, Kevin wrote:
> >> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> >> Sent: Sunday, November 11, 2018 10:07 PM
> &
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Wednesday, November 14, 2018 6:23 PM
>
> This allows to safely use nestedhvm functions that rely on the values
> inside struct nestedvcpu independently of the nested virtualisation
> (HVM_PARAM_NESTEDHVM) status of a domain.
>
> Sign
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, November 15, 2018 9:53 PM
>
> The referenced addresses also need checking against MAXPHYSADDR.
>
> Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
___
Xen-devel mailing list
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, November 15, 2018 9:53 PM
>
> These have been obsolete since c/s 053ae230 "x86/vvmx: Remove enum
> vmx_regs_enc".
>
> Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
___
Xen
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, November 15, 2018 9:53 PM
>
> * Don't assume that decode_vmx_inst() always returns
> X86EMUL_EXCEPTION.
> * The okay boolean is never written, making the else case dead.
>
> Signed-off-by: Andrew Cooper
Acked-by: Kevin
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, November 15, 2018 11:31 PM
>
> On 15/11/2018 15:28, Sergey Dyasli wrote:
> > On 15/11/2018 13:52, Andrew Cooper wrote:
> >> This ends up corrupting L1's view of RFLAGS by setting ZF. The correct
> value
> >> is established
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 21, 2018 9:21 PM
>
> Seemingly, a majority of users either override the helpers anyway, or have
> an
> gfn_t in their hands.
>
> Update the API, and adjust all users to match.
>
> Doing this highlighted a gaping
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 15, 2018 7:11 PM
>
> >>> On 12.01.18 at 19:01, wrote:
> > For performance reasons, HVM guests should have direct access to these
> MSRs
> > when possible.
> >
> > Signed-off-by: Andrew Cooper
>
> Reviewed-by: Jan Beulich
>
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, January 5, 2018 4:21 AM
>
> DMA-ing to the stack is generally considered bad practice. In this case, if a
> timeout occurs because of a sluggish device which is processing the request,
> the completion notification will corr
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, January 18, 2018 11:46 PM
>
> For performance reasons, HVM guests should have direct access to these
> MSRs
> when possible.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Jun Nakajima
> CC: Kevin Tian
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 23, 2018 6:17 PM
>
> It being a field of struct domain is sufficient to recognize its
> purpose.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Wei Liu
> Reviewed-by: George Dunlap
> Reviewed-by: Andrew Cooper
> ---
> v2:
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, January 24, 2018 10:12 PM
>
> The use of __LINE__ in printk()'s is problematic for livepatching, as it tends
> to cause unnecessary binary differences.
>
> Take this opportunity to provide some rather more useful informat
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, January 26, 2018 9:17 PM
>
> * Rename to decode_gpr() to be more specific as to its purpose
> * Drop the highbyte encoding handling, as users care, and it unlikely that
>future users would care.
> * Change to a static
> From: Roger Pau Monne
> Sent: Tuesday, September 1, 2020 6:55 PM
>
> Such handling consist in checking that no bits have been changed from
> the read value, if that's the case silently drop the write, otherwise
> inject a fault.
>
> At least Windows guests will expect to write to the MISC_ENAB
> From: Roger Pau Monne
> Sent: Tuesday, September 1, 2020 6:55 PM
>
> From: Andrew Cooper
>
> Change the catch-all behavior for MSR not explicitly handled. Instead
> of allow full read-access to the MSR space and silently dropping
> writes return an exception when the MSR is not explicitly han
> From: Jan Beulich
> Sent: Thursday, August 27, 2020 3:09 PM
>
> Doing this just in hvm_emulate_one_insn() is not enough.
> hvm_ud_intercept() and hvm_emulate_one_vm_event() can get invoked for
> insns requiring one or more continuations, and at least in principle
> hvm_emulate_one_mmio() could,
> From: Roger Pau Monne
> Sent: Monday, September 7, 2020 6:32 PM
>
> Linux PV guests will attempt to read the FEATURE_CONTROL MSR, so move
> the handling done in VMX code into guest_rdmsr as it can be shared
> between PV and HVM guests that way.
>
> Note that there's a slight behavior change an
201 - 300 of 585 matches
Mail list logo
