From: Paul Durrant
All non-MMIO ranges (i.e those not mapping real device MMIO regions) that
map valid MFNs are normally marked MTRR_TYPE_WRBACK and 'ipat' is set. Hence
when PV drivers running in a guest populate the BAR space of the Xen Platform
PCI Device with pages such as the Shared Info
> -Original Message-
> From: Paul Durrant
> Sent: 31 July 2020 14:44
> To: 'Jan Beulich'
> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ;
> 'Andrew Cooper'
> ; 'Wei Liu' ; 'Roger Pau Monné'
>
> Subject: RE: [PATCH v2 2/2] x86/hvm: s
> -Original Message-
> From: Jan Beulich
> Sent: 31 July 2020 14:41
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ;
> 'Andrew Cooper'
> ; 'Wei Liu' ; 'Roger Pau Monné'
>
> Subject: Re: [PATCH v2 2/2] x86/hvm: s
> -Original Message-
> From: Jan Beulich
> Sent: 31 July 2020 13:58
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
>
> Subject: Re: [PATCH v2 2/2] x86/hvm: simplify 'mmio_direct' che
From: Paul Durrant
All non-MMIO ranges (i.e those not mapping real device MMIO regions) that
map valid MFNs are normally marked MTRR_TYPE_WRBACK and 'ipat' is set. Hence
when PV drivers running in a guest populate the BAR space of the Xen Platform
PCI Device with pages such as the Shared Info
From: Paul Durrant
Re-factor the code to take advantage of the fact that the APIC access page is
a 'special' page.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
---
xen/arch/x86/hvm/m
From: Paul Durrant
This series was originally a singleton (of patch #1)
Paul Durrant (2):
x86/hvm: set 'ipat' in EPT for special pages
x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()
xen/arch/x86/hvm/mtrr.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions
> -Original Message-
> From: Andrew Cooper
> Sent: 31 July 2020 12:21
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Jan Beulich ; Wei
> Liu ; Roger
> Pau Monné
> Subject: Re: [PATCH] x86/hvm: set 'ipat' in EPT for special pages
>
> -Original Message-
> From: Jan Beulich
> Sent: 31 July 2020 12:15
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
>
> Subject: Re: [PATCH] x86/hvm: set 'ipat' in EPT for special pag
From: Paul Durrant
All non-MMIO ranges (i.e those not mapping real device MMIO regions) that
map valid MFNs are normally marked MTRR_TYPE_WRBACK and 'ipat' is set. Hence
when PV drivers running in a guest populate the BAR space of the Xen Platform
PCI Device with pages such as the Shared Info
From: Paul Durrant
There is currently no documentation to state what MTU a frontend should
adertise to its network stack. It has however long been assumed that the
default value of 1500 is correct.
This patch specifies a mechanism to allow the tools to set the MTU via a
xenstore node
From: Paul Durrant
set_mtu() currently sets the backend vif MTU but does not inform the frontend
what it is. This patch adds code to write the MTU into a xenstore node. See
netif.h for a specification of the node.
NOTE: There is also a small modification replacing '$mtu' with '${mtu
From: Paul Durrant
... as they are in vif-route.
The script is invoked with online/offline for vifs and add/remove for taps.
The operations that are necessary, however, are the same in both cases. This
patch therefore combines the cases.
The open-coded bridge removal code is also replaced
From: Paul Durrant
This patch adds a remove_from_bridge() function into xen-network-common.sh
to partner with the existing add_to_bridge() function. The code in
add_to_bridge() is also slightly re-arranged to avoid duplication calls of
'ip link'.
Both add_to_bridge() and remove_from_bridge
From: Paul Durrant
This is long missing functionality
Paul Durrant (4):
tools/hotplug: add remove_from_bridge() and improve debug output
tools/hotplug: combine add/online and remove/offline in vif-bridge...
public/io/netif: specify MTU override node
tools/hotplug: modify set_mtu
; 'Hubert Jasudowicz'
> Subject: Re: [PATCH 1/5] xen/memory: Introduce CONFIG_ARCH_ACQUIRE_RESOURCE
>
> On 30/07/2020 09:02, Paul Durrant wrote:
> >> -Original Message-
> >> From: Andrew Cooper
> >> Sent: 28 July 2020 12:37
> >> To: Xen-devel
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_table_level(). If the list is empty then IOMMU mappings would
not have been enabled
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 straightforward to simply define a helper
function to return the appropriate value
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(...)
if ( !rc )
rc = err;
With this change, it can be simplified to:
rc = iommu_map
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 patch simply makes them consistent with each other.
Signed-off-by: Paul Durrant
---
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Jan
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 in iommu_domain_init() since
it is now done (correctly) in VT-d specific code
From: Paul Durrant
Instead of having separate page table allocation functions in VT-d and AMD
IOMMU code, we could use a common allocation function in the general x86 code.
This patch adds a new allocation function, iommu_alloc_pgtable(), for this
purpose. The function adds the page table pages
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_flush_iotlb' global and the optimization it
facilitates. It is now checked
From: Paul Durrant
The VT-d and AMD IOMMU both use the general x86 IOMMU page table allocator
and ARM always shares page tables with CPU. Hence there is no need to retain
the free_page_table() method or the tasklet which invokes it.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
v2:
- New
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 and cache thrashing as well
as shortening the code.
The scope
From: Paul Durrant
This is v2 of my original 6 patch series. The original patch #3 has
been dropped and the original patch #2 carved up into 4. There are
an additional 2 patches that were not in v1 in any form.
Paul Durrant (10):
x86/iommu: re-arrange arch_iommu to separate common fields
From: Paul Durrant
This patch converts the AMD IOMMU code to use the new 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 and cache thrashing as well
as shortening the code.
Signed-off-by: Paul
> -Original Message-
> From: Roger Pau Monné
> Sent: 30 July 2020 11:08
> To: Jan Beulich
> Cc: Andrew Cooper ;
> xen-devel@lists.xenproject.org; George Dunlap
> ; Ian Jackson ; Julien
> Grall ;
> Stefano Stabellini ; Wei Liu ; Paul
> Durrant ; Kevin
&g
> -Original Message-
> From: Andrew Cooper
> Sent: 28 July 2020 12:37
> To: Xen-devel
> Cc: Andrew Cooper ; Ian Jackson
> ; Wei Liu
> ; Paul Durrant ; Michał Leszczyński
> ; Hubert
> Jasudowicz
> Subject: [PATCH 5/5] tools/foreignmem: Support q
> -Original Message-
> From: Xen-devel On Behalf Of Andrew
> Cooper
> Sent: 28 July 2020 12:37
> To: Xen-devel
> Cc: Hubert Jasudowicz ; Stefano Stabellini
> ; Julien
> Grall ; Wei Liu ; Konrad Rzeszutek Wilk
> ; George
> Dunlap ; Andrew Cooper
&g
> -Original Message-
> From: Andrew Cooper
> Sent: 28 July 2020 12:37
> To: Xen-devel
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Jan Beulich ; Konrad
> Rzeszutek Wilk
> ; Stefano Stabellini ; Wei
> Liu ; Julien
> Grall ; Paul Durrant ;
> -Original Message-
> From: Andrew Cooper
> Sent: 28 July 2020 12:37
> To: Xen-devel
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Jan Beulich ; Konrad
> Rzeszutek Wilk
> ; Stefano Stabellini ; Wei
> Liu ; Julien
> Grall ; Paul Durrant ;
> -Original Message-
> From: Andrew Cooper
> Sent: 28 July 2020 12:37
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Wei Liu ;
> Roger Pau Monné ; Stefano Stabellini
> ; Julien Grall
> ; Volodymyr Babchuk ; Paul
> Durrant ; Michał
> Leszczyński
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: 28 July 2020 11:09
> To: qemu-de...@nongnu.org
> Cc: Paul Durrant ; Paolo Bonzini ;
> xen-devel@lists.xenproject.org;
> Stefano Stabellini ; Anthony Perard
> ; Philippe
> Mathieu-Daudé ; Paul
From: Paul Durrant
The recent commit da278d58a092 "accel: Move Xen accelerator code under
accel/xen/" introduced a subtle semantic change, making xen_enabled() always
return false unless CONFIG_XEN is defined prior to inclusion of sysemu/xen.h,
which appears to be the normal case. T
> -Original Message-
> From: Andrew Cooper
> Sent: 24 July 2020 19:39
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Kevin Tian ;
> Jan Beulich
>
> Subject: Re: [PATCH 3/6] iommu: remove iommu_lookup_page() and the
> lookup_page() m
> -Original Message-
> From: Andrew Cooper
> Sent: 24 July 2020 18:29
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Lukasz Hawrylko
> ; Jan Beulich
> ; Wei Liu ; Roger Pau Monné
> ; Kevin Tian
>
> Subject: Re: [PATCH 1/6] x8
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_table_level(). If the list is empty then IOMMU mappings would
not have been enabled
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_flush_iotlb' global and the optimization it
facilitates. It is now checked
From: Paul Durrant
Sharing of HAP tables is VT-d specific so the operation is never defined for
AMD IOMMU. There's also no need to pro-actively set vtd.pgd_maddr when using
shared EPT as it is straightforward to simply define a helper function to
return the appropriate value in the shared
From: Paul Durrant
Instead of having separate page table allocation functions in VT-d and AMD
IOMMU code, use a common allocation function in the general x86 code.
Also, rather than walking the page tables and using a tasklet to free them
during iommu_domain_destroy(), add allocated page table
From: Paul Durrant
... from iommu_ops.
This patch is essentially a reversion of dd93d54f "vtd: add lookup_page method
to iommu_ops". The code was intended to be used by a patch that has long-
since been abandoned. Therefore it is dead code and can be removed.
Signed-off-by: Pa
From: Paul Durrant
Patches accumulated in my during 4.14 freeze...
Paul Durrant (6):
x86/iommu: re-arrange arch_iommu to separate common fields...
x86/iommu: add common page-table allocator
iommu: remove iommu_lookup_page() and the lookup_page() method...
remove remaining uses
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 in iommu_domain_init() since
it is now done (correctly) in VT-d specific code
://xenproject.org/2020/07/24/xen-project-hypervisor-version-4-14-brings-added-security-and-performance
Thanks everyone who contributed to this release. This release would
not have happened without all the awesome contributions from the Xen
community around the globe.
Regards,
Paul Durrant (on behalf
> -Original Message-
> From: Julien Grall
> Sent: 22 July 2020 17:59
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ;
> Stefano Stabellini ; Wei Liu
> Subject: Re: [P
From: Paul Durrant
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Stefano Stabellini
Cc: Wei Liu
Obviously this has my implicit Release-acked-by and is to be committed to
the staging-4.14 branch only
Jul 06, 2020 at 09:58:53AM +0100, Paul Durrant wrote:
> > > -Original Message-
> > > From: Roger Pau Monné
> > > Sent: 06 July 2020 09:32
> > > To: p...@xen.org
> > > Cc: 'Andrew Cooper' ; 'Jan Beulich'
> > > ; xen-
>
fix code generation for python
> 2.6
>
>
>
> > On Jul 21, 2020, at 10:23 AM, Paul Durrant wrote:
> >
> >> -Original Message-
> >> From: Andrew Cooper
> >> Sent: 21 July 2020 10:21
> >> To: p...@xen.org; 'Nick Rosbrook' ;
&g
nlight: fix code generation for python
> 2.6
>
> On 21/07/2020 08:13, Paul Durrant wrote:
> >> -Original Message-
> >> From: Nick Rosbrook
> >> Sent: 21 July 2020 00:55
> >> To: xen-devel@lists.xenproject.org
> >> Cc: p...@xen.org; Nick
> -Original Message-
> From: Nick Rosbrook
> Sent: 21 July 2020 00:55
> To: xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Nick Rosbrook ; George Dunlap
> ;
> Ian Jackson ; Wei Liu
> Subject: [PATCH for-4.14] golang/xenlight: fix code generation for python 2.6
>
> Before python
igned-off-by: Julien Grall
> >>
> >> Acked-by: Andrew Cooper
> >>
> >> Although I'd suggest the subject be changed rearranged to "Spell
> >> Experimentally correctly".
> >
> > Did you intend to write "Experimental" rather than "Experimentally"?
>
> Erm, yes :)
>
Since this is a small docs change...
Release-acked-by: Paul Durrant
...and please commit to staging-4.14 a.s.a.p.
Data.Text.Internal.Encoding.decodeUtf8:
> Invalid UTF-8 stream
> make: *** [Makefile:236: html/misc/hypfs-paths.html] Error 1
>
> Fixes: 5a4a411bde4 ("docs: specify stability of hypfs path documentation")
> Signed-off-by: Andrew Cooper
Release-acked-by: Paul Durran
e, e.g. due to scope widening or narrowing (e.g. being
> > limited to a specific architecture).
> >
> > Signed-off-by: Juergen Gross
> > Release-acked-by: Paul Durrant
>
> Acked-by: Jan Beulich
>
> Paul - should I throw this in right away, or has it now rather missed
> the train?
I guess our emails raced. Throw it in now.
Paul
>
> Jan
(e.g. being
> limited to a specific architecture).
>
> Signed-off-by: Juergen Gross
> Release-acked-by: Paul Durrant
TBC, this is also exempt from the commit moratorium as it really needs to be in
4.14.
Paul
> ---
> V2: reworded as requested by Jan Beulich
> V3:
> -Original Message-
> From: Xen-devel On Behalf Of
> Christian Lindig
> Sent: 20 July 2020 09:39
> To: Elliott Mitchell ; xen-de...@lists.xen.org
> Cc: Ian Jackson ; Edwin Torok
> ; w...@xen.org;
> d...@recoil.org
> Subject: Re: [PATCH 2/2] tools/ocaml: Default to useful build output
>
> -Original Message-
> From: Brian Marcotte
> Sent: 16 July 2020 21:24
> To: Paul Durrant
> Cc: p...@xen.org; 'Jules' ; xen-devel@lists.xenproject.org;
> oleksandr_gryt...@epam.com; w...@xen.org
> Subject: Re: [EXTERNAL] [Xen-devel] XEN Qdisk Ceph rbd support brok
> -Original Message-
> From: Brian Marcotte
> Sent: 15 July 2020 20:17
> To: Durrant, Paul
> Cc: Jules ; xen-devel@lists.xenproject.org;
> oleksandr_gryt...@epam.com; w...@xen.org
> Subject: RE: [EXTERNAL] [Xen-devel] XEN Qdisk Ceph rbd support broken?
>
> CAUTION: This email
, please CC relevant maintainers and me (p...@xen.org).
Paul Durrant
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2020 13:05
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monné
> ; Wei Liu
> ; Paul Durrant
> Subject: [PATCH 3/3] x86/HVM: fold both instances of looking up a
> hvm_ioreq_vc
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2020 13:04
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monné
> ; Wei Liu
> ; Paul Durrant
> Subject: [PATCH 2/3] x86/HVM: re-work hvm_wait_for_io() a little
>
> Convert the
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2020 13:04
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monné
> ; Wei Liu
> ; Paul Durrant
> Subject: [PATCH 1/3] x86/HVM: fold hvm_io_assist() into its only caller
>
>
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2020 12:57
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant ;
> Wei Liu ;
> Roger Pau Monné
> Subject: [PATCH v3 1/2] x86: restore pv_rtc_handler() invocation
>
> This
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2020 10:47
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant ;
> Wei Liu ;
> Roger Pau Monné
> Subject: [PATCH v2 1/2] x86: restore pv_rtc_handler() invocation
>
> This
ce the
final wording is agreed then consider it...
Release-acked-by: Paul Durrant
> ---
> docs/misc/hypfs-paths.pandoc | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
> index a111c6f25c..7ad4b7b
> -Original Message-
> From: Souptick Joarder
> Sent: 12 July 2020 04:40
> To: boris.ostrov...@oracle.com; jgr...@suse.com; sstabell...@kernel.org
> Cc: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org; Souptick
> Joarder
> ; John Hubbard ; Paul Durrant
> -Original Message-
> From: Souptick Joarder
> Sent: 12 July 2020 04:40
> To: boris.ostrov...@oracle.com; jgr...@suse.com; sstabell...@kernel.org
> Cc: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org; Souptick
> Joarder
> ; John Hubbard ; Paul Durrant
> -Original Message-
> From: Souptick Joarder
> Sent: 12 July 2020 04:40
> To: boris.ostrov...@oracle.com; jgr...@suse.com; sstabell...@kernel.org
> Cc: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org; Souptick
> Joarder
> ; John Hubbard ; Paul Durrant
://wiki.xenproject.org/wiki/Xen_Project_Test_Days and test instructions at
https://wiki.xenproject.org/wiki/Xen_4.14_RC_test_instructions.
Paul Durrant
> -Original Message-
> From: Andrew Cooper
> Sent: 06 July 2020 16:47
> To: Jan Beulich ; xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Roger Pau Monné ; Paul
> Durrant
> Subject: Re: [PATCH] x86emul: fix FXRSTOR test for most AMD CPUs
>
> On 06/07/20
> -Original Message-
> From: Roger Pau Monné
> Sent: 06 July 2020 09:32
> To: p...@xen.org
> Cc: 'Andrew Cooper' ; 'Jan Beulich'
> ; xen-
> de...@lists.xenproject.org; 'Wei Liu'
> Subject: Re: vPT rework (and timer mode)
>
> On Mon, Jul 06, 2020 at 08:03:
> -Original Message-
> From: Andrew Cooper
> Sent: 03 July 2020 16:03
> To: Jan Beulich ; Roger Pau Monné
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Paul Durrant
>
> Subject: Re: vPT rework (and timer mode)
>
> On 03/07/2020 15:50, Jan Beulich wro
> -Original Message-
> From: Wei Liu
> Sent: 03 July 2020 21:11
> To: Anthony PERARD
> Cc: Paul Durrant ; xen-devel@lists.xenproject.org; Roger Pau
> Monné
> ; Ian Jackson ; Wei Liu
>
> Subject: Re: [XEN PATCH for-4.14] Config: Update QEMU
>
> On Fri,
> -Original Message-
> From: Tim Deegan
> Sent: 03 July 2020 21:27
> To: Wei Liu
> Cc: Xen Development List ; Michael Young
> ;
> Paul Durrant ; Ian Jackson
> Subject: Re: [PATCH for-4.14] kdd: fix build again
>
> At 20:10 + on 03 Jul (1593807001), We
> -Original Message-
> From: Xen-devel On Behalf Of Olaf
> Hering
> Sent: 02 July 2020 19:38
> To: Michael Young
> Cc: xen-devel@lists.xenproject.org; Tim Deegan
> Subject: Re: Build problems in kdd.c with xen-4.14.0-rc4
>
> On Tue, Jun 30, Michael Young wrote:
>
> > I get the
'Jan Beulich'
> ; 'Stefano Stabellini' ; 'Wei Liu'
>
> Subject: Re: [PATCH v4 06/10] memory: batch processing in acquire_resource()
>
> Hi,
>
> On 03/07/2020 11:52, Paul Durrant wrote:
> >> -Original Message-
> >> From: Julien Grall
> >
> -Original Message-
> From: Julien Grall
> Sent: 03 July 2020 11:36
> To: Michał Leszczyński ;
> xen-devel@lists.xenproject.org
> Cc: luwei.k...@intel.com; tamas.leng...@intel.com; Andrew Cooper
> ; George
> Dunlap ; Ian Jackson ;
> Jan Beulich
> ; Stefano Stabellini ; Wei Liu
> ;
> -Original Message-
> From: Michael Young
> Sent: 03 July 2020 10:49
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Tim Deegan'
> Subject: RE: Build problems in kdd.c with xen-4.14.0-rc4
>
> On Fri, 3 Jul 2020, Paul Durrant wrote:
>
> >>
> -Original Message-
> From: Xen-devel On Behalf Of Michael
> Young
> Sent: 30 June 2020 23:22
> To: xen-devel@lists.xenproject.org
> Cc: Tim Deegan
> Subject: Build problems in kdd.c with xen-4.14.0-rc4
>
> I get the following errors when trying to build xen-4.14.0-rc4
>
> kdd.c: In
> -Original Message-
> From: Xen-devel On Behalf Of Anthony
> PERARD
> Sent: 02 July 2020 15:26
> To: Paul Durrant
Emails to this address are probably going to /dev/null by now :-)
> Cc: xen-devel@lists.xenproject.org; Roger Pau Monné
> Subject: Re: [PATCH v5] x
> -Original Message-
> From: Jan Beulich
> Sent: 02 July 2020 08:45
> To: Paul Durrant
> Cc: Anthony PERARD ;
> xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
>
> -Original Message-
> From: Jan Beulich
> Sent: 01 July 2020 11:23
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano
> Stabellini ; Roger Pau Monné ;
> Paul Durrant
>
>
> -Original Message-
> From: Jan Beulich
> Sent: 01 July 2020 13:27
> To: Andrew Cooper
> Cc: Xen-devel ; Wei Liu ; Roger
> Pau Monné
> ; Paul Durrant
> Subject: Re: [PATCH for-4.14] x86/spec-ctrl: Protect against CALL/JMP
> straight-line speculation
>
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: 30 June 2020 18:27
> To: p...@xen.org; xen-devel@lists.xenproject.org; qemu-de...@nongnu.org
> Cc: 'Eduardo Habkost' ; 'Michael S. Tsirkin'
> ; 'Paul Durrant'
> ; 'Jason Andryuk' ; 'Paolo Bonzini'
>
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: 30 June 2020 16:26
> To: Paul Durrant ; xen-devel@lists.xenproject.org;
> qemu-de...@nongnu.org
> Cc: Eduardo Habkost ; Michael S. Tsirkin
> ; Paul Durrant
> ; Jason Andryuk ; Paolo Bonzini
> ;
>
> -Original Message-
> From: Anthony PERARD
> Sent: 30 June 2020 16:09
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org; Eduardo Habkost
> ;
> Michael S. Tsirkin ; Paul Durrant ;
> Jason Andryuk
> ; Paolo Bonzini ; Richard
g the result of page walks performed by the spurious
> > fault handler.
> >
> > Just passing this new flag when calling flush_area_mask prevents the
> > usage of the assisted flush without any other side effects.
> >
> > Note the flag is not defined on Arm.
> >
> > Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when
> > available')
> > Reported-by: Andrew Cooper
> > Signed-off-by: Roger Pau Monné
>
> Acked-by: Julien Grall
>
And...
Release-acked-by: Paul Durrant
provided vai the PV Shim mechanism.
> + compatiblity can be provided via the PV Shim mechanism.
>
> config SHADOW_PAGING
> bool "Shadow Paging"
Since it's trivial and cosmetic only this can go in 4.14, so...
Reviewed-by: Paul Durrant
Release-acked-by: Paul Durrant
://wiki.xenproject.org/wiki/Xen_Project_Test_Days and test instructions at
https://wiki.xenproject.org/wiki/Xen_4.14_RC_test_instructions.
Paul Durrant
> -Original Message-
> From: Andrew Cooper
> Sent: 29 June 2020 14:51
> To: Ian Jackson
> Cc: Xen-devel ; Wei Liu ;
> Daniel De Graaf
> ; Paul Durrant
> Subject: Re: [PATCH] tools/configure: drop BASH configure variable
>
> On 29/06/2020 14:34, Ian Ja
> -Original Message-
> From: Andrew Cooper
> Sent: 29 June 2020 11:31
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Wei Liu ;
> Roger Pau Monné ; Paul Durrant
> Subject: [PATCH] x86/boot: Don't disable PV32 when XEN_SHSTK is compiled out
>
> The
w Cooper wrote:
> > Signed-off-by: Andrew Cooper
> > ---
> > CC: Daniel De Graaf
>
> Since we've not heard anything from Daniel in quite a while, just
> in case:
> Acked-by: Jan Beulich
>
This is pretty trivial cleanup so, if you want to put it in 4.14 consider it...
Release-acked-by: Paul Durrant
>
> Jan
ptr == 0 is the normal situation.
> >>> This is the special case, when OP-TEE treats this buffer as a NULL. So
> >>> we are doing nothing there. Thus, "return 0".
> >>>
> >>> But, as Julien pointed out, we can have machine where 0x0 is the valid
> >>> memory address and there is a chance, that some guest will use it as a
> >>> pointer to buffer.
> >>>
> >>>> Aside from this, and the small grammar issue, everything else looks fine
> >>>> to me.
> >>>>
> >>>> Let's wait for Julien's reply, but if this is the only thing I could fix
> >>>> on commit.
> >>
> >> I agree with Volodymyr, this is the normal case here. There are more work
> >> to
> >> prevent MFN 0 to be mapped in the guest but this shouldn't be an issue
> >> today.
> >
> > Let's put the MFN 0 issue aside for a moment.
> >
> > From the commit message I thought that if the guest wanted to pass a
> > NULL buffer ("Null memory reference") then it would also *not* set
> > OPTEE_MSG_ATTR_NONCONTIG, which would be handled by the "else" statement
> > also modified by this patch. Thus, I thought that reaching
> > translate_noncontig with buf_ptr == NULL would always be an error.
> >
> > But re-reading the commit message and from both your answers it is not
> > the case: a "Null memory reference" is allowed with
> > OPTEE_MSG_ATTR_NONCONTIG set too.
> >
> > Thus, I have no further comments and the improvements on the in-code
> > comment could be done on commit.
>
> Good :). IIRC Paul gave a provisional RaB for this series. @Paul, now
> that we are settled, could we get a formal one?
Sure.
Release-acked-by: Paul Durrant
>
> Cheers,
>
> --
> Julien Grall
> -Original Message-
> From: Andrew Cooper
> Sent: 26 June 2020 18:01
> To: Xen-devel
> Cc: Andrew Cooper ; Ian Jackson
> ; Wei Liu
> ; Daniel De Graaf ; Paul Durrant
>
> Subject: [PATCH] tools/configure: drop BASH configure variable
>
> This is a we
ot going to be possible to use the padding
> > for extending a command in the future.
> >
> > Signed-off-by: Julien Grall
>
> With above fixed:
>
> Reviewed-by: Juergen Gross
>
Release-acked-by: Paul Durrant
>
> Juergen
l out it is only provided for reference.
> >
> > [1]
> > https://lore.kernel.org/xen-devel/alpine.DEB.2.21.2006151343430.9074@sstabellini-ThinkPad-T480s/
> >
> > Signed-off-by: Julien Grall
>
> Reviewed-by: Juergen Gross
>
Release-acked-by: Paul Durrant
>
> Juergen
and after this patch, since the structures in the memory.h
> compat header are subject to a pragma pack(4), which already removed
> the trailing padding that would otherwise be introduced by the
> alignment of the frame field to 8 bytes.
>
> Fixes: 3f8f12281dd20 ('x86/mm: add HYPE
> -Original Message-
> From: Andrew Cooper
> Sent: 26 June 2020 15:38
> To: Xen-devel
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Jan Beulich ; Konrad
> Rzeszutek Wilk
> ; Stefano Stabellini ; Wei
> Liu ; Julien
> Grall ; Paul Durrant
>
'
> ; 'Volodymyr
> Babchuk'
> Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage
>
> On Fri, Jun 26, 2020 at 02:58:21PM +0100, Julien Grall wrote:
> > On 26/06/2020 14:21, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: J
> -Original Message-
> From: Jan Beulich
> Sent: 26 June 2020 14:15
> To: Andrew Cooper
> Cc: Xen-devel ; Wei Liu ; Roger
> Pau Monné
> ; Konrad Rzeszutek Wilk ; Ross
> Lagerwall
> ; Pawel Wieczorkiewicz ; Paul
> Durrant
> Subject: Re: [PATCH
801 - 900 of 3550 matches
Mail list logo
