Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
drivers/net/xen-netfront.c | 36 +---
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/net/xen-netfront.c
Many Xen PV frontends share similar code for setting up a ring page
(allocating and granting access for the backend) and for tearing it
down.
Create new service functions doing all needed steps in one go.
This requires all frontends to use a common value for an invalid
grant reference in order
There is no external user of xenbus_grant_ring() left, so merge it into
the only caller xenbus_setup_ring().
Signed-off-by: Juergen Gross
---
drivers/xen/xenbus/xenbus_client.c | 64 +-
include/xen/xenbus.h | 2 -
2 files changed, 18 insertions(+), 48
On Wed, Apr 20, 2022 at 05:09:28PM +0200, Juergen Gross wrote:
> Instead of using a private macro for an invalid grant reference use
> the common one.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/usb/host/xen-hcd.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
On Wed, Apr 20, 2022 at 05:09:40PM +0200, Juergen Gross wrote:
> Simplify xen-hcd's ring creation and removal via xenbus_setup_ring()
> and xenbus_teardown_ring().
>
> Signed-off-by: Juergen Gross
> ---
> drivers/usb/host/xen-hcd.c | 55 +-
> 1 file changed,
On 20.04.22 16:57, Luca Fancellu wrote:
On 11 Apr 2022, at 16:20, Luca Fancellu wrote:
Cpu0 must remain in cpupool0, otherwise some operations like moving cpus
between cpupools, cpu hotplug, destroying cpupools, shutdown of the host,
might not work in a sane way.
Signed-off-by: Luca
On 20/04/2022 07:26, Jan Beulich wrote:
On 19.04.2022 17:01, David Vrabel wrote:
From: David Vrabel
Heap pages can only be safely allocated and freed with interuupts
enabled as they may require a TLB flush which will send IPIs.
Enhance the assertions in alloc_xenheap_pages() and
flight 169567 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169567/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
> On 13 Apr 2022, at 08:22, Jan Beulich wrote:
>
> On 13.04.2022 09:15, Luca Fancellu wrote:
>>
No, I'm not suggesting a new menu. I was merely wondering whether the
Kconfig contents wouldn't location-wise better match where the
respective source file lives.
>>>
>>> It
> On 11 Apr 2022, at 16:20, Luca Fancellu wrote:
>
> Cpu0 must remain in cpupool0, otherwise some operations like moving cpus
> between cpupools, cpu hotplug, destroying cpupools, shutdown of the host,
> might not work in a sane way.
>
> Signed-off-by: Luca Fancellu
> ---
> Changes in v7:
>
On 20.04.22 17:22, Andrew Cooper wrote:
On 20/04/2022 16:09, Juergen Gross wrote:
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index 1a2e0d94ccd1..7b1f7f86b6e5 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@
flight 169560 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169560/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169545
test-armhf-armhf-libvirt 16
On 20.04.22 16:00, Luca Fancellu wrote:
On 13 Apr 2022, at 08:22, Jan Beulich wrote:
On 13.04.2022 09:15, Luca Fancellu wrote:
No, I'm not suggesting a new menu. I was merely wondering whether the
Kconfig contents wouldn't location-wise better match where the
respective source file
flight 169568 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169568/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
When CONFIG_GDBSX is compiled out, iommu_do_domctl() falls over a NULL
pointer. It isn't really correct for processing of XEN_DOMCTL_gdbsx_* to fall
into the default case when compiled out.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei Liu
On Wed, 20 Apr 2022, Fabio M. De Francesco wrote:
> On mercoledì 20 aprile 2022 08:03:05 CEST Julia Lawall wrote:
> >
> > On Wed, 20 Apr 2022, Alaa Mohamed wrote:
> >
> > > kmap() is being deprecated and these usages are all local to the thread
> > > so there is no reason kmap_local_page()
On mercoledì 20 aprile 2022 15:40:10 CEST Julia Lawall wrote:
>
> On Wed, 20 Apr 2022, Fabio M. De Francesco wrote:
>
> > On mercoledì 20 aprile 2022 08:03:05 CEST Julia Lawall wrote:
> > >
> > > On Wed, 20 Apr 2022, Alaa Mohamed wrote:
> > >
> > > > kmap() is being deprecated and these usages
On 20.04.22 17:56, Andrew Cooper wrote:
When CONFIG_GDBSX is compiled out, iommu_do_domctl() falls over a NULL
pointer. It isn't really correct for processing of XEN_DOMCTL_gdbsx_* to fall
into the default case when compiled out.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan
Just a couple of nits.
On 4/20/22 5:25 AM, Juergen Gross wrote:
-static int scsifront_ring_drain(struct vscsifrnt_info *info)
+static int scsifront_ring_drain(struct vscsifrnt_info *info,
+ unsigned int *eoiflag)
{
- struct vscsiif_response *ring_rsp;
+
On mercoledì 20 aprile 2022 15:57:14 CEST Julia Lawall wrote:
>
> On Wed, 20 Apr 2022, Fabio M. De Francesco wrote:
>
> > On mercoledì 20 aprile 2022 15:40:10 CEST Julia Lawall wrote:
> > >
> > > On Wed, 20 Apr 2022, Fabio M. De Francesco wrote:
> > >
> > > > On mercoledì 20 aprile 2022 08:03:05
There are now instances where internal hypervisor logic needs to make resource
allocation calls that are protectd by XSM checks. The internal hypervisor logic
is represented a number of system domains which by designed are represented by
non-privileged struct domain instances. To enable these
This series makes it so that the idle domain is started privileged under the
default policy, which the SILO policy inherits, and under the flask policy. It
then introduces a new one-way XSM hook, xsm_transition_running, that is hooked
by an XSM policy to transition the idle domain to its running
On 20/04/2022 16:09, Juergen Gross wrote:
> diff --git a/drivers/xen/xenbus/xenbus_client.c
> b/drivers/xen/xenbus/xenbus_client.c
> index 1a2e0d94ccd1..7b1f7f86b6e5 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -433,9 +390,24 @@ int
On 4/20/22 5:25 AM, Juergen Gross wrote:
@@ -569,7 +645,7 @@ static void scsiback_device_action(struct vscsibk_pend
*pending_req,
wait_for_completion(_req->tmr_done);
err = (se_cmd->se_tmr_req->response == TMR_FUNCTION_COMPLETE) ?
- SUCCESS : FAILED;
+
On Wed, 20 Apr 2022, Fabio M. De Francesco wrote:
> On mercoledì 20 aprile 2022 15:40:10 CEST Julia Lawall wrote:
> >
> > On Wed, 20 Apr 2022, Fabio M. De Francesco wrote:
> >
> > > On mercoledì 20 aprile 2022 08:03:05 CEST Julia Lawall wrote:
> > > >
> > > > On Wed, 20 Apr 2022, Alaa Mohamed
common/gdbstub.c wants struct gdb_context but only gets it transitively
through asm/debugger.h. None of */gdbstub.c should include asm/debugger.h so
include xen/gdbstub.h instead.
Forward declare struct cpu_user_regs in xen/gdbstub.h so it doesn't depend on
the include order to compile.
From: Bobby Eshleman
With all the non-CONFIG_CRASH_DEBUG functionality moved elsewhere, split
x86/debugger.h in two, with the stubs and explanation moved to xen/debugger.h.
In particular, this means that arches only need to provide an $arch/debugger.h
if they implement CONFIG_CRASH_DEBUG, and
domain_pause_for_debugger() is guest debugging (CONFIG_GDBSX) not host
debugging (CONFIG_CRASH_DEBUG).
Move it into the new gdbsx.c to drop the (incorrect) ifdefary, and provide a
static inline in the !CONFIG_GDBSX case so callers can optimise away
everything rather than having to emit a call to
This work is primarily to prevent new architectures from needing to implement
a stub debugger.h for something that is in practice only implemented on x86,
and probably bitrotten into oblivion. It also resolves a lot of technical
debt on the x86 side.
Andrew Cooper (3):
x86/gdbsx: Move
* Remove inappropriate semicolon from debugger_trap_immediate()
* Try to explain what debugger_trap_fatal() is doing, and write it in a more
legible way.
* Drop unecessary includes. This includes common/domain.c which doesn't use
any debugger functionality, even prior to this cleaup.
From: Bobby Eshleman
debug.c contains only dbg_rw_mem(). Rename it to gdbsx.c.
Move gdbsx_guest_mem_io(), and the prior setup of iop->remain, from domctl.c
to gdbsx.c, merging it with dbg_rw_mem().
Signed-off-by: Bobby Eshleman
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau
From: Bobby Eshleman
debugger_trap_entry() is unrelated to the other contents of debugger.h. It is
a no-op for everything other than #DB/#BP, and for those it invokes guest
debugging (CONFIG_GDBSX) not host debugging (CONFIG_CRASH_DEBUG).
Furthermore, the description of how to use
Simplify pcifront's shared page creation and removal via
xenbus_setup_ring() and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/pci/xen-pcifront.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/pci/xen-pcifront.c
Simplify blkfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkfront.c | 34 +++---
1 file changed, 7 insertions(+), 27 deletions(-)
diff --git a/drivers/block/xen-blkfront.c
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
drivers/xen/xen-front-pgdir-shbuf.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/xen/xen-front-pgdir-shbuf.c
Simplify drmfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 40 ++---
1 file changed, 10 insertions(+), 30 deletions(-)
diff --git
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkfront.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/block/xen-blkfront.c
GRANT_INVALID_REF isn't used in scsifront, so remove it.
Signed-off-by: Juergen Gross
---
drivers/scsi/xen-scsifront.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index 761c9c463ecd..9db2366fa2d4 100644
---
Simplify sndfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
sound/xen/xen_snd_front_evtchnl.c | 41 +++
1 file changed, 9 insertions(+), 32 deletions(-)
diff --git
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
drivers/usb/host/xen-hcd.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/xen-hcd.c b/drivers/usb/host/xen-hcd.c
index
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
sound/xen/xen_snd_front_evtchnl.c | 4 ++--
sound/xen/xen_snd_front_evtchnl.h | 9 -
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
drivers/gpu/drm/xen/xen_drm_front.h | 9 -
drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 4 ++--
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
drivers/xen/gntdev-dmabuf.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index
Most PV device frontends share very similar code for setting up shared
ring buffers:
- allocate page(s)
- init the ring admin data
- give the backend access to the ring via grants
Tearing down the ring requires similar actions in all frontends again:
- remove grants
- free the page(s)
Provide
Simplify netfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/net/xen-netfront.c | 49 +-
1 file changed, 11 insertions(+), 38 deletions(-)
diff --git a/drivers/net/xen-netfront.c
Simplify scsifront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/scsi/xen-scsifront.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/scsi/xen-scsifront.c
Simplify xen-hcd's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/usb/host/xen-hcd.c | 55 +-
1 file changed, 13 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/host/xen-hcd.c
Simplify tpmfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/char/tpm/xen-tpmfront.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/char/tpm/xen-tpmfront.c
This commit implements full support for starting the idle domain privileged by
introducing a new flask label xenboot_t which the idle domain is labeled with
at creation. It then provides the implementation for the XSM hook
xsm_transition_running to relabel the idle domain to the existing xen_t
Hi julien
> -Original Message-
> From: Julien Grall
> Sent: Saturday, April 9, 2022 6:59 AM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: nd ; Stefano Stabellini ; Bertrand
> Marquis ; Volodymyr Babchuk
>
> Subject: Re: [PATCH v1 06/13] xen/arm: set up shared memory foreign
>
On 20.04.2022 10:13, David Vrabel wrote:
>
>
> On 20/04/2022 07:26, Jan Beulich wrote:
>> On 19.04.2022 17:01, David Vrabel wrote:
>>> From: David Vrabel
>>>
>>> Heap pages can only be safely allocated and freed with interuupts
>>> enabled as they may require a TLB flush which will send IPIs.
Add a translation layer for the command result values.
Signed-off-by: Juergen Gross
---
drivers/scsi/xen-scsifront.c | 64 +++-
1 file changed, 56 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index
Instead of using the kernel's values for the result of PV scsi
operations use the values of the interface definition.
Signed-off-by: Juergen Gross
---
drivers/xen/xen-scsiback.c | 82 --
1 file changed, 79 insertions(+), 3 deletions(-)
diff --git
Instead of relying on a well behaved PV scsi backend verify all meta
data received from the backend and avoid multiple reads of the same
data from the shared ring page.
In case any illegal data from the backend is detected switch the
PV device to a new "error" state and deactivate it for further
Update the Xen PV-scsi interface from the Xen tree and adapt the
related drivers to use the new definitions.
Harden the frontend driver to be no longer vulnerable to a malicious
backend.
Juergen Gross (4):
xen: update vscsiif.h
xen/scsiback: use new command result macros
xen/scsifront: use
On Wed, 20 Apr 2022, Fabio M. De Francesco wrote:
> On mercoledì 20 aprile 2022 08:03:05 CEST Julia Lawall wrote:
> >
> > On Wed, 20 Apr 2022, Alaa Mohamed wrote:
> >
> > > kmap() is being deprecated and these usages are all local to the thread
> > > so there is no reason kmap_local_page()
Hi,
I have the following setup and try to test the Function Level Reset feature.
Any suggestions or pointers will be very much helpful.
DOM0
Distribution: Ubuntu-20.04.3 (kernel 5.8.0-43)
Xen version : 4.11.4-pre
DOMU
Distribution: Ubuntu-18.04.6 LTS (kernel 5.8.0)
PCIe device with SRIOV
On 20.04.2022 14:48, Naresh Bhat wrote:
> I have the following setup and try to test the Function Level Reset feature.
> Any suggestions or pointers will be very much helpful.
>
> DOM0
> Distribution: Ubuntu-20.04.3 (kernel 5.8.0-43)
> Xen version : 4.11.4-pre
>
> DOMU
> Distribution:
flight 169561 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169561/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Hi
> -Original Message-
> From: Julien Grall
> Sent: Saturday, April 9, 2022 5:31 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: nd ; Stefano Stabellini ; Bertrand
> Marquis ; Volodymyr Babchuk
>
> Subject: Re: [PATCH v1 06/13] xen/arm: set up shared memory foreign
>
On 14.04.2022 13:47, Andrew Cooper wrote:
> There are no .S intermediate files, so rework in terms of head-bin-objs.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
> CC: Anthony PERARD
>
> I'm slightly -1 on this,
On mercoledì 20 aprile 2022 08:03:05 CEST Julia Lawall wrote:
>
> On Wed, 20 Apr 2022, Alaa Mohamed wrote:
>
> > kmap() is being deprecated and these usages are all local to the thread
> > so there is no reason kmap_local_page() can't be used.
> >
> > Replace kmap() calls with kmap_local_page().
The claimed reason for setting errno to -1 is wrong. On x86
xc_domain_pod_target() will set errno to a sane value in the error
case.
Signed-off-by: Juergen Gross
---
tools/libs/ctrl/xc_domain.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/libs/ctrl/xc_domain.c
libxl_domain_setmaxmem() called during "xl mem-max" should update the
domain's memory/static-max Xenstore node, as otherwise "xl mem-set"
won't be able to set the memory size to the new maximum.
Adjust the related comments and documentation accordingly.
Signed-off-by: Juergen Gross
---
V2:
-
flight 169550 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169550/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169541
test-amd64-amd64-qemuu-nested-amd
On 20.04.22 08:20, Henry Wang wrote:
Hi Oleksandr,
Hi Henry
-Original Message-
From: Oleksandr Tyshchenko
Subject: [PATCH V7 2/2] libxl: Introduce basic virtio-mmio support on Arm
From: Julien Grall
This patch introduces helpers to allocate Virtio MMIO params
(IRQ and memory
flight 169564 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169564/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Update include/xen/interface/io/vscsiif.h to its newest version.
Signed-off-by: Juergen Gross
---
include/xen/interface/io/vscsiif.h | 133 -
1 file changed, 129 insertions(+), 4 deletions(-)
diff --git a/include/xen/interface/io/vscsiif.h
On 14.04.2022 13:47, Andrew Cooper wrote:
> --- a/xen/arch/x86/boot/build32.lds
> +++ b/xen/arch/x86/boot/build32.lds
> @@ -31,44 +31,36 @@ SECTIONS
> *(.bss.*)
>}
>
> + /* Dynamic linkage sections. Collected simply so we can check they're
> empty. */
> + .got : {
> +
Hi Marco,
The block script is timeout, you can add some log message to
check what happened to “/etc/xen/scripts/block add”.
You can google to a lot of pages on how to print messages in
Linux shell scripts.
libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute:
On 14.04.2022 20:35, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Needless to say that the generated System.map may not represent reality
if xen.efi is what is in actual use.
Jan
flight 169555 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169555/
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
On 14.04.2022 18:27, Andrew Cooper wrote:
> There's no point wasting time converting binaries back to asm source. Just
> use .incbin directly. Explain in head.S what these binaries are.
Hmm, yes. Why in the world did we do this all these years?
> Also, align the blobs. While there's very
On 20/04/2022 13:11, Jan Beulich wrote:
> On 14.04.2022 18:27, Andrew Cooper wrote:
>> There's no point wasting time converting binaries back to asm source. Just
>> use .incbin directly. Explain in head.S what these binaries are.
> Hmm, yes. Why in the world did we do this all these years?
One
Setting errno to a negative error value makes no sense.
Signed-off-by: Juergen Gross
---
tools/libs/guest/xg_dom_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libs/guest/xg_dom_core.c b/tools/libs/guest/xg_dom_core.c
index c17cf9f712..c4f4e7f3e2 100644
---
Setting errno to a negative value makes no sense.
Signed-off-by: Juergen Gross
---
tools/libs/evtchn/freebsd.c | 2 +-
tools/libs/evtchn/minios.c | 2 +-
tools/libs/evtchn/netbsd.c | 2 +-
tools/libs/evtchn/solaris.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git
Setting errno to a negative value makes no sense.
Signed-off-by: Juergen Gross
---
tools/libs/light/libxl_linux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libs/light/libxl_linux.c b/tools/libs/light/libxl_linux.c
index 8d62dfd255..27f2bce718 100644
---
There are a few places in the libs where errno is set to a negative
value. Fix those.
Juergen Gross (4):
tools/libs/evtchn: don't set errno to negative values
tools/libs/ctrl: don't set errno to a negative value
tools/libs/guest: don't set errno to a negative value
tools/libs/light: don't
Hello Stefano, Juergen
On 20.04.22 03:23, Stefano Stabellini wrote:
On Tue, 19 Apr 2022, Oleksandr wrote:
On 19.04.22 17:48, Juergen Gross wrote:
On 19.04.22 14:17, Oleksandr wrote:
Hello Stefano, Juergen
On 18.04.22 22:11, Stefano Stabellini wrote:
On Mon, 18 Apr 2022, Oleksandr
Hi all,
I did several attempts but I have always problems with disk backend setup
during creation of domU domain.
The latest attempt was using deban arm64 image with this configuration:
memory = 512
name = "debian"
vcpus = 1
maxvcpus = 1
kernel = "/home/xen/vmlinuz"
ramdisk =
flight 169566 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169566/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 169569 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169569/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169571 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169571/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 20/04/2022 18:49, Andrew Cooper wrote:
> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/2355562119
>
> ld: prelink.o: in function `vtd_setup':
> drivers/passthrough/vtd/iommu.c:(.init.text+0x219f6): undefined
> reference to `opt_hap_2mb'
>
On Wed, Apr 20, 2022 at 1:02 PM Daniel P. Smith
wrote:
>
> There are now instances where internal hypervisor logic needs to make resource
> allocation calls that are protectd by XSM checks. The internal hypervisor
> logic
> is represented a number of system domains which by designed are
On 4/20/22 11:09 AM, Juergen Gross wrote:
+/*
+ * xenbus_setup_ring
+ * @dev: xenbus device
+ * @vaddr: pointer to starting virtual address of the ring
+ * @nr_pages: number of pages to be granted
+ * @grefs: grant reference array to be filled in
+ *
+ * Allocate physically contiguous pages
On 4/20/22 14:31, Jason Andryuk wrote:
> On Wed, Apr 20, 2022 at 1:02 PM Daniel P. Smith
> wrote:
>>
>> There are now instances where internal hypervisor logic needs to make
>> resource
>> allocation calls that are protectd by XSM checks. The internal hypervisor
>> logic
>> is represented a
On Wed, 20 Apr 2022, Wei Chen wrote:
> > On Tue, 19 Apr 2022, Wei Chen wrote:
> > > > > ### 3.2. Xen Event Channel Support
> > > > > In Current RFC patches we haven't enabled the event channel
> > support.
> > > > > But I think it's good opportunity to do some discussion in
> > advanced.
>
On Mon, Apr 18, 2022 at 3:44 AM Dmitry Osipenko
wrote:
>
> On 4/15/22 21:14, Rafael J. Wysocki wrote:
> > Honestly, I would prefer this to be split so as to make it easier to
> > review if nothing else.
>
> I'll try to split it in v8.
>
> > On Tue, Apr 12, 2022 at 1:39 AM Dmitry Osipenko
> >
flight 169562 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169562/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169547
test-armhf-armhf-libvirt 16
flight 169563 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169563/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169426
test-amd64-i386-xl-qemut-win7-amd64 19
On Wed, Apr 20, 2022 at 1:03 PM Daniel P. Smith
wrote:
>
> This commit implements full support for starting the idle domain privileged by
> introducing a new flask label xenboot_t which the idle domain is labeled with
> at creation. It then provides the implementation for the XSM hook
>
https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/2355562119
ld: prelink.o: in function `vtd_setup':
drivers/passthrough/vtd/iommu.c:(.init.text+0x219f6): undefined
reference to `opt_hap_2mb'
drivers/passthrough/vtd/iommu.c:(.init.text+0x219f6): relocation
truncated to fit: R_X86_64_PC32
On 4/20/22 14:07, Jason Andryuk wrote:
> On Wed, Apr 20, 2022 at 1:03 PM Daniel P. Smith
> wrote:
>>
>> This commit implements full support for starting the idle domain privileged
>> by
>> introducing a new flask label xenboot_t which the idle domain is labeled with
>> at creation. It then
On Mon, Apr 18, 2022 at 3:29 AM Dmitry Osipenko
wrote:
>
> On 4/14/22 14:19, Rafael J. Wysocki wrote:
> > On Thu, Apr 14, 2022 at 12:24 AM Dmitry Osipenko
> > wrote:
> >>
> >> On 4/13/22 21:48, Rafael J. Wysocki wrote:
> >>> On Tue, Apr 12, 2022 at 1:39 AM Dmitry Osipenko
> >>> wrote:
>
>
On Mon, 18 Apr 2022, Wei Chen wrote:
> In current code, when Xen is booting from EFI, it will delete
> all memory nodes in device tree. This would work well in current
> stage, because Xen can get memory map from EFI system table.
> However, EFI system table cannot completely replace memory nodes
On Mon, 18 Apr 2022, Wei Chen wrote:
> VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
> results in two lines of error-checking code in phys_to_nid
> that is not actually working and causing two compilation
> errors:
> 1. error: "MAX_NUMNODES" undeclared (first use in this function).
>
flight 169578 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169578/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169570 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169570/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Wed, 20 Apr 2022, Oleksandr wrote:
> On 20.04.22 03:23, Stefano Stabellini wrote:
> > On Tue, 19 Apr 2022, Oleksandr wrote:
> > > On 19.04.22 17:48, Juergen Gross wrote:
> > > > On 19.04.22 14:17, Oleksandr wrote:
> > > > > Hello Stefano, Juergen
> > > > >
> > > > >
> > > > > On 18.04.22
1 - 100 of 135 matches
Mail list logo
