branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
testid xen-boot
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.g
flight 142606 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142606/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 142521 REGR.
vs. 139698
Tests which
On 10/11/19 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
scripts/coccinelle/auto-propagated-errp.cocci | 118 ++
1 file changed, 118 insertions(+)
create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci
diff --gi
On 10/11/19 12:12 PM, Eric Blake wrote:
On 10/11/19 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
+@@
+identifier rule1.fn;
+identifier rule1.local_err;
+@@
+
+ fn(...)
+ {
+ <...
+(
+- error_free(local_err);
+- local_err = NULL;
++
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
CC: Gerd Hoffmann
CC: "Gonglei (Arei)"
CC: Eduardo Habkost
CC: Igor Mammedov
CC: Laurent Vivier
CC: Amit Shah
CC: Kevin Wolf
CC: Max Reitz
CC: John Snow
CC: Ari Sundholm
CC: Pavel Dovgalyuk
CC: Paolo Bonzini
CC: Stefan Hajnoczi
CC: Fam
Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with errp OUT parameter.
It has three goals:
1. Fix issue with error_fatal & error_prepend/error_append_hint: user
can't see this additional information, because exit() happens in
error_setg earlier than information is
Add script to automatically commit tree-wide changes per-subsystem.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
CC: Gerd Hoffmann
CC: "Gonglei (Arei)"
CC: Eduardo Habkost
CC: Igor Mammedov
CC: Laurent Vivier
CC: Amit Shah
CC: Kevin Wolf
CC: Max Reitz
CC: John Snow
CC: Ari Sundholm
Hi all!
At the request of Markus: full version of errp propagation. Let's look
at it. Cover as much as possible, except inserting macro invocation
where it's not necessary.
It's huge, and so it's an RFC.
In v5 I've added a lot more preparation cleanups:
01-23 are preparation cleanups
01: not c
On 10/11/19 11:03 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
At the request of Markus: full version of errp propagation. Let's look
at it. Cover as much as possible, except inserting macro invocation
where it's not necessary.
It's huge, and so it's an RFC.
Is there a repo containing thes
flight 142598 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142598/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 141822
test-arm64-arm64-e
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xen
flight 142599 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142599/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423
test-amd64-amd64-xl-qemuu
flight 142594 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142594/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-examine 8 reboot fail like 142539
test-amd64-i386-libvirt-pair 10 xen-bo
flight 142588 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-xl-
On 10/11/19 8:01 PM, Stefano Stabellini wrote:
On Fri, 11 Oct 2019, Julien Grall wrote:
Hi Stefano,
On 10/11/19 6:11 PM, Stefano Stabellini wrote:
This is not pretty, but I don't view this as critical to fix for Xen 4.13.
So
I am thinking to defer this post 4.13.
If the issue doesn't trigg
On Fri, Oct 11, 2019 at 07:17:29PM +0100, Julien Grall wrote:
> Hi,
>
> On 10/11/19 7:06 PM, Brian Woods wrote:
> >On Fri, Oct 11, 2019 at 05:58:35PM +0100, Julien Grall wrote:
> >For that, you'd need to either check the start and end of the added
> >module or the start of both. So something like
On Fri, 11 Oct 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 10/11/19 6:11 PM, Stefano Stabellini wrote:
> > > This is not pretty, but I don't view this as critical to fix for Xen 4.13.
> > > So
> > > I am thinking to defer this post 4.13.
> >
> > If the issue doesn't trigger on 4.13, then I agr
> >>> +be prefixed with header/magic and its size, e.g.:
> >>> +
> >>> + kernel_info:
> >>> + .ascii "LToP" /* Header, Linux top (structure). */
> >>> + .long kernel_info_var_len_data - kernel_info
> >>> + .long kernel_info_end - kernel_info
> >>> +
Hi,
On 10/11/19 7:06 PM, Brian Woods wrote:
On Fri, Oct 11, 2019 at 05:58:35PM +0100, Julien Grall wrote:
For that, you'd need to either check the start and end of the added
module or the start of both. So something like:
if ( ((mod->start >= start) && (mod->start < (start + size))) ||
(
On Fri, Oct 11, 2019 at 05:58:35PM +0100, Julien Grall wrote:
> Hi,
>
> Please at least remove the signature in the e-mail you reply to. The best
> would be to trim the e-mail and answer right below the specific paragraph.
>
> >
> >To make sure the module is going to get added, you'd need to do t
Hi Stefano,
On 10/11/19 6:11 PM, Stefano Stabellini wrote:
This is not pretty, but I don't view this as critical to fix for Xen 4.13. So
I am thinking to defer this post 4.13.
If the issue doesn't trigger on 4.13, then I agree we shouldn't try to
fix it (badly) at this stage.
But we do have a
flight 142586 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142586/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
140282
test-amd64-amd
On Fri, 11 Oct 2019, Lars Kurth wrote:
> On 11/10/2019, 02:24, "Stefano Stabellini" wrote:
>
> On Thu, 10 Oct 2019, Lars Kurth wrote:
> > * Would we ever include API docs generated from GPLv2 code? E.g. for
> safety use-cases?
> > @Stefano, @Artem: I guess this one is for you.
>
On Fri, 11 Oct 2019, Lars Kurth wrote:
> On 11/10/2019, 09:32, "Jan Beulich" wrote:
>
> On 10.10.2019 20:30, Lars Kurth wrote:
> > On 10/10/2019, 18:05, "Andrew Cooper" wrote:
> > On 10/10/2019 13:34, Lars Kurth wrote:
> > > Existing formats and licenses
> > > *
On Fri, 11 Oct 2019, Julien Grall wrote:
> Hi,
>
> On 11/10/2019 16:23, Ian Jackson wrote:
> > Oleksandr Grytsov writes ("[PATCH v1] libxl: Add DTB compatible list to
> > config file"):
> > > From: Oleksandr Grytsov
> > >
> > > Some platforms need more compatible property values in device
> > >
On Fri, 11 Oct 2019, Julien Grall wrote:
> On 11/10/2019 01:32, Stefano Stabellini wrote:
> > On Thu, 10 Oct 2019, Julien Grall wrote:
> > > On 08/10/2019 23:24, Stefano Stabellini wrote:
> > > > On Tue, 8 Oct 2019, Julien Grall wrote:
> > > > > On 10/8/19 1:18 AM, Stefano Stabellini wrote:
> > > >
Oleksandr Grytsov writes ("Re: [PATCH v1 1/2] libxl: introduce new backend type
VINPUT"):
> On Fri, Oct 11, 2019 at 5:58 PM Ian Jackson wrote:
> > I think it was a48e00f14a2d "libxl: add backend type and id to vkb"
> > which introduced what you are calling "user space" backends. It
> > appears t
Hi,
On 10/11/19 5:43 PM, Brian Woods wrote:
On Thu, Oct 10, 2019 at 04:39:07PM +0100, Julien Grall wrote:
Hi Brian,
Thank you for the patch.
On 10/9/19 8:47 PM, Brian Woods wrote:
It's possible for a misconfigured device tree to cause Xen to crash when
there are overlapping addresses in the
These are now redundant because shadow_memkb and iommu_memkb are now
defaulted automatically by libxl_domain_need_memory and
libxl_domain_create etc. Callers should not now call these; instead,
they should just let libxl take care of it.
libxl_get_required_shadow_memory was introduced in f89f5558
We need this before we start to figure out the passthrough mode.
I have checked that nothing in libxl__domain_create_info_setdefault
nor the two implementations of ..._arch_... accesses anything else,
other than (i) the domain type (which this function is responsible for
setting and nothing before
This is v3 of my series to sort out the shadow/iommu memory and pci
passthrough situation. It is also available here:
https://xenbits.xen.org/gitweb/?p=people/iwj/xen.git;a=summary
wip.libxl-memkb-ptcfg.v3
Thanks to Andrew Cooper and Julien Grall for comments about the PT
mode setting, whic
Defaulting is supposed to be done by libxl. So these calculations
should be here in libxl. libxl__domain_config_setdefault has all the
necessary information including the values of max_memkb and max_vcpus.
The overall functional effect depends on the caller:
For xl, no change. The code moves f
LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
version of this code) is doing double duty. We actually need all of
the following to be specificable:
* default ("unspecified"): enable PT iff we have devices to
pass through specified in the initial config file.
* "enabled
No functional change. This will let us refer to it in code we are
about to add to this function.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
---
v2: New patch in this version of the series.
---
tools/libxl/libxl_create.c | 17 -
tools/libxl/libxl_dm.c | 7 ++-
too
No functional change. This will let us make it into a pointer without
textual change other than to the definition.
While we are here, fix some style errors (missing { }).
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
---
v2: New patch in this version of the series.
---
tools/libxl/libxl_create
On Thu, Oct 10, 2019 at 04:39:07PM +0100, Julien Grall wrote:
> Hi Brian,
>
> Thank you for the patch.
>
> On 10/9/19 8:47 PM, Brian Woods wrote:
> >It's possible for a misconfigured device tree to cause Xen to crash when
> >there are overlapping addresses in the memory modules. Add a warning
>
Jürgen Groß writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
Overhaul passthrough setting logic"):
> On 11.10.19 15:31, Ian Jackson wrote:
> > I do not have a strong opinion about this. I would be happy with
> > "auto" (or "default" maybe).
>
> "unspecified"?
That is IMO the best
flight 142595 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142595/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501
Tests which did
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == &fatal_err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want t
Hi,
On 11/10/2019 16:23, Ian Jackson wrote:
Oleksandr Grytsov writes ("[PATCH v1] libxl: Add DTB compatible list to config
file"):
From: Oleksandr Grytsov
Some platforms need more compatible property values in device
tree root node in addition to "xen,xenvm-%d.%d" and "xen,xenvm"
values that
On Fri, Oct 11, 2019 at 5:58 PM Ian Jackson wrote:
>
> Oleksandr Grytsov writes ("[PATCH v1 1/2] libxl: introduce new backend type
> VINPUT"):
> > From: Oleksandr Grytsov
> >
> > There are two kind of VKBD devices: with QEMU backend and user space
> > backend. In current implementation they can'
Roger Pau Monne writes ("Re: [PATCH v1 2/2] libxl: add removing XS backend path
for PV devices on domain destroy"):
> When this code was added (devd) those where the only backends handled
> by libxl. VDISPL, VSND, VINPUT didn't exist at that point, so I think
> the issue is that when support for t
On Fri, Oct 11, 2019 at 04:02:53PM +0100, Andrew Cooper wrote:
> The virtual address of the base of the IOMMU's regsters is not useful for
> diagnostic purposes, and is quite voluminous. The PCI coordinates is by far
> the most useful piece of identifying information.
>
> Signed-off-by: Andrew Co
On Fri, Oct 11, 2019 at 04:07:11PM +0100, Ian Jackson wrote:
> Oleksandr Grytsov writes ("[PATCH v1 2/2] libxl: add removing XS backend path
> for PV devices on domain destroy"):
> > From: Oleksandr Grytsov
> >
> > Currently backend path is remove for specific devices: VBD, VIF, QDISK.
> > This
Oleksandr Grytsov writes ("[PATCH v1] libxl: Add DTB compatible list to config
file"):
> From: Oleksandr Grytsov
>
> Some platforms need more compatible property values in device
> tree root node in addition to "xen,xenvm-%d.%d" and "xen,xenvm"
> values that are given by Xen by default.
> Specif
Oleksandr Grytsov writes ("[PATCH v1] Reset iomem's gfn to LIBXL_INVALID_GFN on
reboot"):
> During domain reboot its configuration is partially reused
> to re-create a new domain, but iomem's GFN field for the
> iomem is only restored for those memory ranges, which are
> configured in form of [IOM
Oleksandr Grytsov writes ("[PATCH v1 2/2] libxl: add removing XS backend path
for PV devices on domain destroy"):
> From: Oleksandr Grytsov
>
> Currently backend path is remove for specific devices: VBD, VIF, QDISK.
> This commit adds removing backend path for: VDISPL, VSND, VINPUT.
Thanks for
The virtual address of the base of the IOMMU's regsters is not useful for
diagnostic purposes, and is quite voluminous. The PCI coordinates is by far
the most useful piece of identifying information.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Jun Naka
Oleksandr Grytsov writes ("[PATCH v1 1/2] libxl: introduce new backend type
VINPUT"):
> From: Oleksandr Grytsov
>
> There are two kind of VKBD devices: with QEMU backend and user space
> backend. In current implementation they can't be distinguished as both use
> VKBD backend type. As result, us
flight 142584 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142584/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 142252
test-armhf-armhf-libvirt-raw 13 saveresto
On 11.10.19 15:31, Ian Jackson wrote:
George Dunlap writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
Overhaul passthrough setting logic"):
On Thu, Oct 10, 2019 at 4:12 PM Ian Jackson wrote:
LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
version of this code)
Julien Grall writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
Overhaul passthrough setting logic"):
> libxl treats Arm guest as PVH now. Note that we seamlessly convert
> PV to PVH in libxl__arch_domain_{build, create}_info_setdefault().
>
> So as long as this is called after any of
(+ Andrew and Jan)
Hi,
On 11/10/2019 01:27, Stefano Stabellini wrote:
On Thu, 10 Oct 2019, Julien Grall wrote:
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index be23acfe26..a6637ce347 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -964,11 +964,40 @@ static int create_xen_tabl
George Dunlap writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
Overhaul passthrough setting logic"):
> On Thu, Oct 10, 2019 at 4:12 PM Ian Jackson wrote:
> > LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
> > version of this code) is doing double duty. We actual
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenb
flight 142571 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142571/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 142521 REGR.
vs. 139698
Tests which
Hi Stefano,
On 11/10/2019 01:27, Stefano Stabellini wrote:
On Thu, 10 Oct 2019, Julien Grall wrote:
The current implementations of xen_{map, unmap}_table() expect
{map, unmap}_domain_page() to be usable. Those helpers are used to
map/unmap page tables while update Xen page-tables.
Since commit
On 11/10/2019, 09:32, "Jan Beulich" wrote:
On 10.10.2019 20:30, Lars Kurth wrote:
> On 10/10/2019, 18:05, "Andrew Cooper" wrote:
> On 10/10/2019 13:34, Lars Kurth wrote:
> > Existing formats and licenses
> > * Hypercall ABI Documentation generated from Xen publ
On Thu, Oct 10, 2019 at 4:12 PM Ian Jackson wrote:
>
> LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
> version of this code) is doing double duty. We actually need all of
> the following to be specificable:
> * default ("unknown"): enable PT iff we have devices to
> pas
Introduce new C macros for annotations of functions and data in
assembly. There is a long-standing mess in macros like ENTRY, END,
ENDPROC and similar. They are used in different manners and sometimes
incorrectly.
So introduce macros with clear use to annotate assembly as follows:
a) Support macr
There is a couple of assembly functions, which are invoked only locally
in the file they are defined. In C, they are marked "static". In
assembly, annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch
their ENDPROC to SYM_{FUNC,CODE}_END too). Whether FUNC or CODE is used,
depends on whether
All these are functions which are invoked from elsewhere, but they are
not typical C functions. So they are annotated using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END appropriately too.
Signed-off-by: Jiri Slaby
Reviewed-by: Boris Ostrovsk
These are all functions which are invoked from elsewhere, so annotate
them as global using the new SYM_FUNC_START. And their ENDPROC's by
SYM_FUNC_END.
And make sure ENTRY/ENDPROC is not defined on X86_64, given these were
the last users.
Signed-off-by: Jiri Slaby
Reviewed-by: Rafael J. Wysocki
_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy as it
All these are functions which are invoked from elsewhere, but they are
not typical C functions. So they are annotated using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END, appropriately.
Signed-off-by: Jiri Slaby
Reviewed-by: Boris Ostrovsky
Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros to have:
8 OBJECT LOCAL DEFAULT6 gdt
000832 OBJECT LOCAL DEFAULT6 gdt_start
0028 0 OBJECT LOCAL DEFAULT6 gdt_end
0028 256 OBJECT LOCAL DEFAULT6 early_stack
0128 0 OBJECT LOCAL DEFAU
Here, all assembly code which is marked using END (and not ENDPROC) is
changed. All these are switched to appropriate new markings
SYM_CODE_START and SYM_CODE_END.
Signed-off-by: Jiri Slaby
Reviewed-by: Boris Ostrovsky [xen bits]
Cc: Borislav Petkov
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H.
On 11/10/2019, 02:24, "Stefano Stabellini" wrote:
On Thu, 10 Oct 2019, Lars Kurth wrote:
> * Would we ever include API docs generated from GPLv2 code? E.g. for
safety use-cases?
> @Stefano, @Artem: I guess this one is for you.
> I suppose if we would have a similar issue for
flight 142567 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142567/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423
test-amd64-amd64-xl-qemuu
Hi,
On 11/10/2019 10:47, Andrew Cooper wrote:
On 10/10/2019 16:11, Ian Jackson wrote:
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 69971c97b6..fccb6a6271 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -968,6 +957,50 @@ int libxl__domain
flight 142563 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142563/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR.
vs. 141822
test-amd6
Hi Lars
On Thu, 2019-10-10 at 12:34 +, Lars Kurth wrote:
> * Possibly stuff such as
> https://urldefense.com/v3/__https://xenbits.xen.org/docs/unstable/support-matrix.html__;!K6dmGCEab4ueJg!lwAwYJi7cUkbX7CUXnOD9i7laj_9xcyafF714u6PO04tu0CYUKDHWBHAy2XD0mvEiA$
> (which is currently GPL-2,
>
On Fri, Oct 11, 2019 at 12:01:36PM +0200, Jan Beulich wrote:
> On 11.10.2019 11:28, Roger Pau Monné wrote:
> > On Fri, Oct 11, 2019 at 09:52:35AM +0200, Jan Beulich wrote:
> >> On 10.10.2019 17:19, Roger Pau Monné wrote:
> >>> On Thu, Oct 10, 2019 at 03:46:45PM +0200, Jan Beulich wrote:
> On
Hi,
On 11/10/2019 01:32, Stefano Stabellini wrote:
On Thu, 10 Oct 2019, Julien Grall wrote:
On 08/10/2019 23:24, Stefano Stabellini wrote:
On Tue, 8 Oct 2019, Julien Grall wrote:
On 10/8/19 1:18 AM, Stefano Stabellini wrote:
On Mon, 7 Oct 2019, Julien Grall wrote:
Hi,
On 03/10/2019 02:02,
Andrew Cooper writes ("Re: [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul
passthrough setting logic"):
> On 10/10/2019 16:11, Ian Jackson wrote:
> > +if (c_info->passthrough == LIBXL_PASSTHROUGH_DISABLED && need_pt) {
> > +LOGD(ERROR, domid,
> > + "passthrough disabled but
On 11.10.2019 11:28, Roger Pau Monné wrote:
> On Fri, Oct 11, 2019 at 09:52:35AM +0200, Jan Beulich wrote:
>> On 10.10.2019 17:19, Roger Pau Monné wrote:
>>> On Thu, Oct 10, 2019 at 03:46:45PM +0200, Jan Beulich wrote:
On 10.10.2019 15:12, Roger Pau Monné wrote:
> On Thu, Oct 10, 2019 a
Not commenting on the patch, but I had exactly the same problem when
removing the direct map in x86. map_domain_page has to be usable
without the direct map and even before alloc_boot_pages can be used (so
that I can map the bootmem_regions_list, although I have made it
statically allocated now).
On 10/10/2019 16:11, Ian Jackson wrote:
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 69971c97b6..fccb6a6271 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -968,6 +957,50 @@ int libxl__domain_config_setdefault(libxl__gc *gc,
>
On Fri, Oct 11, 2019 at 09:52:35AM +0200, Jan Beulich wrote:
> On 10.10.2019 17:19, Roger Pau Monné wrote:
> > On Thu, Oct 10, 2019 at 03:46:45PM +0200, Jan Beulich wrote:
> >> On 10.10.2019 15:12, Roger Pau Monné wrote:
> >>> On Thu, Oct 10, 2019 at 02:55:02PM +0200, Jan Beulich wrote:
> On
On Thu, Oct 10, 2019 at 04:11:09PM +0100, Ian Jackson wrote:
> No functional change. This will let us make it into a pointer without
> textual change other than to the definition.
>
> While we are here, fix some style errors (missing { }).
>
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
__
On Thu, Oct 10, 2019 at 04:11:11PM +0100, Ian Jackson wrote:
> LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
> version of this code) is doing double duty. We actually need all of
> the following to be specificable:
> * default ("unknown"): enable PT iff we have devices to
>
On Thu, Oct 10, 2019 at 04:11:10PM +0100, Ian Jackson wrote:
> No functional change. This will let us refer to it in code we are
> about to add to this function.
>
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@l
On 10.10.2019 20:30, Lars Kurth wrote:
> On 10/10/2019, 18:05, "Andrew Cooper" wrote:
> On 10/10/2019 13:34, Lars Kurth wrote:
> > Existing formats and licenses
> > * Hypercall ABI Documentation generated from Xen public headers
> > Format: kerndoc
> > License: typically BSD-3
On 10.10.2019 17:19, Roger Pau Monné wrote:
> On Thu, Oct 10, 2019 at 03:46:45PM +0200, Jan Beulich wrote:
>> On 10.10.2019 15:12, Roger Pau Monné wrote:
>>> On Thu, Oct 10, 2019 at 02:55:02PM +0200, Jan Beulich wrote:
On 10.10.2019 14:13, Roger Pau Monné wrote:
> On Thu, Oct 10, 2019 a
84 matches
Mail list logo
