flight 169583 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169583/
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 21.04.2022 01:31, Stefano Stabellini wrote:
>
> Oops, yes I did. Well spotted. Just sending this one update here.
>
>
> ---
> gitlab-ci: add an ARM32 qemu-based smoke test
>
> Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
> the test-artifacts qemu container. The min
flight 169573 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169573/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169562
test-armhf-armhf-libvirt 16 sav
flight 169582 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169582/
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 169580 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169580/
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 169579 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169579/
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 169572 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169572/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169560
test-armhf-armhf-libvirt 16 saver
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
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).
>
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:
> x86 is using compiler feature testing to decide EFI
> build enable or not. When EFI build is disabled, x86
> will use a efi/stub.c file to replace efi/runtime.c
> for build objects. Following this idea, we introduce
> a stub file for Arm, but use CONFIG_ARM_EF
flight 169575 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169575/
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 169565 xen-unstable real [real]
flight 169576 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169565/
http://logs.test-lab.xenproject.org/osstest/logs/169576/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Mon, 18 Apr 2022, Wei Chen wrote:
> Most of the functions in x86 EFI stub.c can be reused for other
> architectures. So we move them to common and keep the x86 specific
> function in stub-x86.c.
>
> Signed-off-by: Wei Chen
Reviewed-by: Stefano Stabellini
> ---
> v1 -> v2:
> 1. Drop the cop
On Mon, 18 Apr 2022, Penny Zheng wrote:
> In order to have an easy and quick way to find out whether this domain memory
> is statically configured, this commit introduces a new flag CDF_staticmem and
> a
> new helper is_domain_static to tell.
>
> Signed-off-by: Penny Zheng
Reviewed-by: Stefano
On Tue, 19 Apr 2022, Michal Orzel wrote:
> On 16.04.2022 02:17, Stefano Stabellini wrote:
> > Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
> > the test-artifacts qemu container. The minimal test simply boots Xen
> > (built from previous build stages) and Dom0.
> >
> > Th
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 22:11
flight 169574 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169574/
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 Wed, 20 Apr 2022, Rahul Singh wrote:
> > On 20 Apr 2022, at 3:36 am, Stefano Stabellini
> > wrote:
> >>> Then there is xen_swiotlb_init() which allocates some memory for
> >>> swiotlb-xen at boot. It could lower the total amount of memory
> >>> available, but if you disabled swiotlb-xen like I
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 1
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 fla
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 logic
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 pr
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, 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.
>
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
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 sav
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 provi
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 numb
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
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
> > wrot
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 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 represent
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
> xsm_trans
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'
> drivers/passthrough/vtd/iommu.c:(.init.text+0x
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 ag
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:
>
> >
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 fla
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 pr
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 logic
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 saver
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 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(&pending_req->tmr_done);
err = (se_cmd->se_tmr_req->response == TMR_FUNCTION_COMPLETE) ?
- SUCCESS : FAILED;
+
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 Beul
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 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 Fancell
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, 1
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(-)
Acked
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
@@ -43
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 xenbus_setup
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 d
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 b/drivers
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 b/d
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 b/drivers/cha
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 b/drivers/pci/x
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 a/drivers/gpu/drm/xen/xen_drm_f
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 b/d
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
b/drivers/xen/xen-f
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 3e487ba
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 a/sound/xen/xen_snd_fron
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
--- a/drivers/scsi/xen-
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 b/drivers/block/xen-blkf
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 a/sound/xen/xen_snd_front_evtchn
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 b/
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 s
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 d5bf
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 a/dr
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 to
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 b/drivers/net/xen-
> 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:
> -
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
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 AR
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.
x86/setu
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 debugger_trap
* 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.
Sig
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 a
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 domain_pa
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 lives
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
> 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 co
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 wr
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 ar
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() can't
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() can't
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().
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: Ubuntu-18
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 suppo
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 o
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 1
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 littl
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, becau
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
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:
/etc/xen/sc
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 = "/home/xen/
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 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 : {
> +*(.g
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
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
b/include/xen/interface/io
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
1 - 100 of 122 matches
Mail list logo
