Hi Thomas,
On 8/11/2020 2:53 AM, Thomas Gleixner wrote:
Thomas Gleixner writes:
CC+: XEN folks
Thomas Gleixner writes:
The infrastructure itself is not more than a thin wrapper around the
existing msi domain infrastructure and might even share code with
platform-msi.
And the annoying fact
flight 152560 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152560/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-qem
On Tue, 11 Aug 2020, Julien Grall wrote:
> On 11/08/2020 00:34, Stefano Stabellini wrote:
> > On Mon, 10 Aug 2020, Julien Grall wrote:
> > > On 07/08/2020 00:48, Stefano Stabellini wrote:
> > > > On Thu, 6 Aug 2020, Julien Grall wrote:
> > > > > On 06/08/2020 01:37, Stefano Stabellini wrote:
> > >
On Tue, 11 Aug 2020, Julien Grall wrote:
> On 11/08/2020 00:34, Stefano Stabellini wrote:
> > On Sat, 8 Aug 2020, Julien Grall wrote:
> > > On Fri, 7 Aug 2020 at 22:51, Stefano Stabellini
> > > wrote:
> > > >
> > > > On Fri, 7 Aug 2020, Jan Beulich wrote:
> > > > > On 07.08.2020 01:49, Stefano St
On Tue, 11 Aug 2020, Oleksandr wrote:
> On 11.08.20 12:19, Julien Grall wrote:
> > On 11/08/2020 00:34, Stefano Stabellini wrote:
> > > On Mon, 10 Aug 2020, Oleksandr wrote:
> > > > On 08.08.20 01:19, Oleksandr wrote:
> > > > > On 08.08.20 00:50, Stefano Stabellini wrote:
> > > > > > On Fri, 7 Aug
"Dey, Megha" writes:
> On 8/11/2020 2:53 AM, Thomas Gleixner wrote:
>>> And the annoying fact that you need XEN support which opens another can
>>> of worms...
>
> hmm I am not sure why we need Xen support... are you referring to idxd
> using xen?
What about using IDXD when you are running on XE
On 11.08.20 11:44, Roger Pau Monne wrote:
> This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
> being used by non DAX devices.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Dan Williams
> Cc: Vishal Verma
> Cc: Dave Jiang
> Cc: Andrew Mo
flight 152559 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152559/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 152555
test-amd64-amd64-xl-qemuu-ws16-amd64
On 11/08/2020 18:09, Oleksandr wrote:
On 05.08.20 12:32, Julien Grall wrote:
Hi Julien, Stefano
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 5fdb6e8..5823f11 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -385,10 +385,11 @@ static in
On 05.08.20 12:32, Julien Grall wrote:
Hi Julien, Stefano
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 5fdb6e8..5823f11 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -385,10 +385,11 @@ static inline int set_foreign_p2m_entry(struct
do
[ Responding to both Jan and Andrew's comments about config parsing
and file sources when secure boot is enabled ]
On Friday, August 7, 2020 2:23 PM, Jan Beulich wrote:
> [...]
> As said before, I think we want an all-or-nothing approach. You
> want to first establish whether the image is a unifi
> -Original Message-
> From: Jan Beulich
> Sent: 06 August 2020 10:57
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Jun Nakajima
> ; Kevin Tian ; Andrew Cooper
> ; George Dunlap ; Wei
> Liu ; Roger Pau
> Monné ; Ian Jackson ; Julien
> Grall ;
> Stefano Stab
On Wed, Jul 22, 2020 at 10:25:17AM +0200, Philippe Mathieu-Daudé wrote:
> Xen accelerator requires specific changes to a machine to be able
> to use it. See for example the 'Xen PC' machine configure its PCI
> bus calling pc_xen_hvm_init_pci(). There is no 'Xen Q35' machine
> declared. This code wa
On Friday, August 7, 2020 2:23 PM, Jan Beulich wrote:
> On 06.08.2020 16:15, Trammell Hudson wrote:
> > --- /dev/null
> > +++ b/xen/arch/x86/efi/pe.c
> > @@ -0,0 +1 @@
> > +../../../common/efi/pe.c
> > \ No newline at end of file
>
> This isn't supposed to be part of the patch; the symlinks get
>
The videos for the XenSummit have all been posted on our YouTube channel:
https://www.youtube.com/playlist?list=PLYyw7IQjL-zFYmEoZEYswoVuXrHvXAWxj
-George
This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
being used by non DAX devices.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Andrew Morton
Cc: Jason Gunthorpe
Cc: Ira Weiny
Cc: "Aneesh Kumar K.V"
Hello,
The following series contain some fixes in order to split Xen
unpopulated memory handling from the ballooning driver if ZONE_DEVICE is
available, so that physical memory regions used to map foreign pages are
not tied to memory hotplug.
The main difference in this version is that MEMORY_DEV
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels without support for
ZONE_DEVICE Xen will fallbac
> On Aug 11, 2020, at 8:41 AM, Roger Pau Monne wrote:
>
> On Mon, Aug 03, 2020 at 03:18:08PM +0200, Jan Beulich wrote:
>> On 31.07.2020 14:35, Jan Beulich wrote:
>>> On 31.07.2020 14:27, George Dunlap wrote:
> On Jul 31, 2020, at 1:25 PM, Jan Beulich wrote:
> On 30.07.2020 17:41, Georg
Resending this straw man patch at Roger's request, to restart discussion.
Redux: In order to cope with the relatively rare case of unmaskable
legacy MSIs, each vlapic EOI takes a domain-global spinlock just to
iterate over all IRQs and determine that there's actually nothing to
do.
In my testing,
flight 152558 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152558/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
Hi Stefano,
On 11/08/2020 00:34, Stefano Stabellini wrote:
On Sat, 8 Aug 2020, Julien Grall wrote:
On Fri, 7 Aug 2020 at 22:51, Stefano Stabellini wrote:
On Fri, 7 Aug 2020, Jan Beulich wrote:
On 07.08.2020 01:49, Stefano Stabellini wrote:
On Thu, 6 Aug 2020, Julien Grall wrote:
On 06/08/
On Mon, Aug 03, 2020 at 03:18:08PM +0200, Jan Beulich wrote:
> On 31.07.2020 14:35, Jan Beulich wrote:
> > On 31.07.2020 14:27, George Dunlap wrote:
> >>> On Jul 31, 2020, at 1:25 PM, Jan Beulich wrote:
> >>> On 30.07.2020 17:41, George Dunlap wrote:
> > On Jul 30, 2020, at 4:17 PM, George Dun
On 11/08/2020 00:34, Stefano Stabellini wrote:
On Mon, 10 Aug 2020, Julien Grall wrote:
On 07/08/2020 00:48, Stefano Stabellini wrote:
On Thu, 6 Aug 2020, Julien Grall wrote:
On 06/08/2020 01:37, Stefano Stabellini wrote:
On Wed, 5 Aug 2020, Julien Grall wrote:
On 04/08/2020 20:11, Stefan
flight 152556 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152556/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-qem
On 11.08.20 12:19, Julien Grall wrote:
Hi Julien, Stefano
Hi Stefano,
On 11/08/2020 00:34, Stefano Stabellini wrote:
On Mon, 10 Aug 2020, Oleksandr wrote:
On 08.08.20 01:19, Oleksandr wrote:
On 08.08.20 00:50, Stefano Stabellini wrote:
On Fri, 7 Aug 2020, Oleksandr wrote:
On 06.08.20 03
Thomas Gleixner writes:
CC+: XEN folks
> Thomas Gleixner writes:
>> The infrastructure itself is not more than a thin wrapper around the
>> existing msi domain infrastructure and might even share code with
>> platform-msi.
>
> And the annoying fact that you need XEN support which opens another
Hi Stefano,
On 11/08/2020 00:34, Stefano Stabellini wrote:
On Mon, 10 Aug 2020, Oleksandr wrote:
On 08.08.20 01:19, Oleksandr wrote:
On 08.08.20 00:50, Stefano Stabellini wrote:
On Fri, 7 Aug 2020, Oleksandr wrote:
On 06.08.20 03:37, Stefano Stabellini wrote:
Hi Stefano
Trying to simulate
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 in the fron
From: Paul Durrant
...and also inform the frontend.
The set_mtu() function in xen-network-common.sh currently sets the backend
vif MTU to match that of the bridge.
A prior patch added code into libxl such that a tools-configured 'mtu' value
may be present in the xenstore backend area. If the no
From: Paul Durrant
The 'add' and 'online' cases do exactly the same thing so have 'add' simply
fall through to 'online'.
NOTE: This patch also adds in the missing 'remove' case, which falls though
to 'offline'. (The former is passed for 'tap' devices, the latter for
'vif' devices).
From: Paul Durrant
This patch adds code to parse a value for MTU from the network configuration
if it is present. The documentation in xl-network-configuration.5.pod is
also modified accordingly.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Anthony PERARD
v3:
- New in v3
From: Paul Durrant
configuration is not parsed by libxl so there is no reason for the hotplug
script to exist
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
v3:
- New in v3
---
tools/hotplug/Linux/Makefile | 1 -
tools/hotplug/Linux/vif2 | 54 -
From: Paul Durrant
Currently the 'mtu' field of libxl_device_nic objects is effectively ignored:
It is set by libxl__device_nic_setdefault() to a slightly odd default value of
1492 but otherwise ignored.
This patch changes the default value to a more conventional 1500 and modifies
libxl__set_xen
From: Paul Durrant
This is an expansion from v2 of the series to include the facility to set
the MTU in the vif config.
There is also one cleanup patch to remove the defunct 'vif2' script.
Paul Durrant (8):
public/io/netif: specify MTU override node
tools/hotplug/Linux: re-factor add_to_bri
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 vif-bridge
script is then modified to use it.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
v3:
- Re-factored from "tools/ho
From: Paul Durrant
Remove duplication of 'ip link set dev'. It is perfectly fine to call it
even if the device has already been added to the bridge.
NOTE: This patch also adds code to write a debug log entry if the device
was already on the bridge.
Signed-off-by: Paul Durrant
---
Cc: Ian
flight 152555 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152555/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 152548
test-amd64-amd64-xl-qemuu-ws16-amd64
38 matches
Mail list logo
