On Thu, May 13, 2021 at 06:56:47PM -0600, Connor Davis wrote:
> Hi all,
>
> This goal of this series is to allow the USB3 debug capability (DbC) to be
> safely used by xen while linux runs as dom0.
Patch 2/4 does not seem to be showing up anywhere, did it get lost?
thanks,
greg k-h
flight 161939 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161939/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-armhf-armhf-xl 5 host-inst
On Thu, May 13, 2021 at 10:17:08PM -0600, Connor Davis wrote:
> Defaulting to yes only for X86 and ARM reduces the requirements
> for a minimal build when porting new architectures.
>
> Signed-off-by: Connor Davis
> ---
> xen/drivers/char/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 delet
On Fri, May 14, 2021 at 2:18 PM Connor Davis wrote:
>
> Hi all,
>
> This series introduces a minimal build for RISCV. It is based on Bobby's
> previous work from last year[0]. I have worked to rebase onto current Xen,
> as well as update the various header files borrowed from Linux.
>
> This serie
> From: Julien Grall
Hi Julien,
>
> On 11/05/2021 02:11, Henry Wang wrote:
> > Hi Julien,
> Hi Henry,
> >
> >> From: Julien Grall
> >> Hi Henry,
> >>
> >> On 07/05/2021 05:06, Henry Wang wrote:
> From: Julien Grall
> On 28/04/2021 10:28, Henry Wang wrote:
> >> [...]
> >>
> >>> when I
Add a container for cross-compiling xen to riscv64.
This just includes the cross-compiler and necessary packages for
building xen itself (packages for tools, stubdoms, etc., can be
added later).
To build xen in the container run the following:
$ make XEN_TARGET_ARCH=riscv64 SUBSYSTEMS=xen
Signed
Move struct grant_table; in grant_table.h above
ifdef CONFIG_GRANT_TABLE. This fixes the following:
/build/xen/include/xen/grant_table.h:84:50: error: 'struct grant_table'
declared inside parameter list will not be visible outside of this
definition or declaration [-Werror]
84 | static inline i
The variables iommu_enabled and iommu_dont_flush_iotlb are defined in
drivers/passthrough/iommu.c and are referenced in common code, which
causes the link to fail when !CONFIG_HAS_PASSTHROUGH.
Guard references to these variables in common code so that xen
builds when !CONFIG_HAS_PASSTHROUGH.
Sign
Hi all,
This series introduces a minimal build for RISCV. It is based on Bobby's
previous work from last year[0]. I have worked to rebase onto current Xen,
as well as update the various header files borrowed from Linux.
This series provides the patches necessary to get a minimal build
working. Th
Defaulting to yes only for X86 and ARM reduces the requirements
for a minimal build when porting new architectures.
Signed-off-by: Connor Davis
---
xen/drivers/char/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
ind
From: "Daniel P. Smith"
Adds a design document for Hyperlaunch, formerly DomB mode of dom0less.
Signed-off-by: Christopher Clark
Signed-off by: Daniel P. Smith
Reviewed-by: Rich Persaud
---
Changes since v3:
* Rename the Landscape table
* Changed Crash Domain to Recovery Domain
* amended t
From: "Daniel P. Smith"
Adds a design document for Hyperlaunch device tree structure.
Signed-off-by: Christopher Clark
Signed-off by: Daniel P. Smith
---
.../designs/launch/hyperlaunch-devicetree.rst | 343 ++
1 file changed, 343 insertions(+)
create mode 100644 docs/designs/
We are submitting for inclusion in the Xen documentation:
- the Hyperlaunch design document, and
- the Hyperlaunch device tree design document
to describe a new method for launching the Xen hypervisor.
The Hyperlaunch feature builds upon prior dom0less work,
to bring a flexible and security-mind
On 3/12/21 10:09 AM, Jan Beulich wrote:
On 25.02.2021 16:24, Connor Davis wrote:
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -106,6 +106,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
#include "../arch-x86/hvm/save.h"
#elif defined(__arm__) || defin
Upon thinking about it, this seems appropriate to bring to the attention
of the Xen development list since it seems to have wider implications.
On Wed, May 12, 2021 at 11:08:39AM +0100, Julien Grall wrote:
> On 12/05/2021 03:37, Elliott Mitchell wrote:
> >
> > What about the approach to the gran
flight 161938 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161938/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-am
On Thu, 13 May 2021, Julien Grall wrote:
> On Thu, 13 May 2021, 23:32 Stefano Stabellini, wrote:
> On Wed, 12 May 2021, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 12/05/2021 23:00, Stefano Stabellini wrote:
> > > On Sun, 25 Apr 2021, Julien Grall wrote:
> >
Callers of dbgp_reset_prep treat a 0 return value as "stop using
the debug port", which means they don't make any subsequent calls to
dbgp_reset_prep or dbgp_external_startup.
To ensure the callers' interpretation is correct, first return -EPERM
from xen_dbgp_op if !xen_initial_domain(). This ensu
Export xen_dbgp_reset_prep and xen_dbgp_external_startup
when CONFIG_XEN_DOM0 is defined. This allows use of these symbols
even if CONFIG_EARLY_PRINK_DBGP is defined.
Signed-off-by: Connor Davis
Acked-by: Juergen Gross
---
drivers/xen/dbgp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Check if the debug capability is enabled in early_xdbc_parse_parameter,
and if it is, return with an error. This avoids collisions with whatever
enabled the DbC prior to linux starting.
Signed-off-by: Connor Davis
---
drivers/usb/early/xhci-dbc.c | 10 ++
1 file changed, 10 insertions(+)
Hi all,
This goal of this series is to allow the USB3 debug capability (DbC) to be
safely used by xen while linux runs as dom0.
The first patch prevents the early DbC driver from using an
already-running DbC.
The second exports xen_dbgp_reset_prep and xen_dbgp_external_startup
functions when CON
On Thu, 13 May 2021, 23:32 Stefano Stabellini,
wrote:
> On Wed, 12 May 2021, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 12/05/2021 23:00, Stefano Stabellini wrote:
> > > On Sun, 25 Apr 2021, Julien Grall wrote:
> > > > From: Julien Grall
> > > >
> > > > Only the first 2GB of the virtual addr
On Sun, 25 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> At the moment, page-table can only be allocated from domheap. This means
> it is not possible to create mapping in the page-tables via
> map_pages_to_xen() if page-table needs to be allocated.
>
> In order to avoid open-coding pag
On Wed, 12 May 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 12/05/2021 22:30, Stefano Stabellini wrote:
> > On Wed, 12 May 2021, Julien Grall wrote:
> > > > > +#define LPAE_SHIFT LPAE_SHIFT_GS(PAGE_SHIFT)
> > > > > +#define LPAE_ENTRIESLPAE_ENTRIES_GS(PAGE_SHIFT)
> > > > > +#def
On Wed, 12 May 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 12/05/2021 23:00, Stefano Stabellini wrote:
> > On Sun, 25 Apr 2021, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > Only the first 2GB of the virtual address space is shared between all
> > > the page-tables on Arm32.
> > >
On Thu, 13 May 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 12/05/2021 23:44, Stefano Stabellini wrote:
> > On Sun, 25 Apr 2021, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > xen_{un,}map_table() already uses the helper to map/unmap pages
> > > on-demand (note this is currently a NO
flight 161936 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161936/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 161937 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161937/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 13/05/2021 04:56, osstest service owner wrote:
> flight 161917 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/161917/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-arm64-arm64-examine 8 re
flight 161924 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161924/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-am
On 11/05/2021 02:11, Henry Wang wrote:
Hi Julien,
Hi Henry,
From: Julien Grall
Hi Henry,
On 07/05/2021 05:06, Henry Wang wrote:
From: Julien Grall
On 28/04/2021 10:28, Henry Wang wrote:
[...]
when I continue booting Xen, I got following error log:
(XEN) CPU:0
(XEN) PC: 00
Hi Stefano,
On 12/05/2021 23:44, Stefano Stabellini wrote:
On Sun, 25 Apr 2021, Julien Grall wrote:
From: Julien Grall
xen_{un,}map_table() already uses the helper to map/unmap pages
on-demand (note this is currently a NOP on arm64). So switching to
domheap don't have any disavantage.
But th
Hi Stefano,
On 12/05/2021 23:07, Stefano Stabellini wrote:
On Sun, 25 Apr 2021, Julien Grall wrote:
From: Julien Grall
Now that map_pages_to_xen() has been extended to support 2MB mappings,
we can replace the create_mappings() call by map_pages_to_xen() call.
Signed-off-by: Julien Grall
--
flight 161922 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161922/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 161926 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161926/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161898
test-armhf-armhf-libvirt 16 save
On 13/05/2021 14:00, Olaf Hering wrote:
> Am Thu, 13 May 2021 13:29:32 +0100
> schrieb Andrew Cooper :
>
>> Warning: NX (Execute Disable) protection not active
> There was a knob in the BIOS, it was set to "Disabled" for some reason.
> Once enabled, the flag is seen and the dom0 starts fine.
>
> If
Am Thu, 13 May 2021 13:29:32 +0100
schrieb Andrew Cooper :
> Warning: NX (Execute Disable) protection not active
There was a knob in the BIOS, it was set to "Disabled" for some reason.
Once enabled, the flag is seen and the dom0 starts fine.
If Xen is booted with 'cpuid=no-nx', the dom0 crashes
Am Thu, 13 May 2021 13:29:32 +0100
schrieb Andrew Cooper :
> Can we first establish whether this box really does, or does not, have NX ?
According to lscpu of a native boot: no.
Architecture: x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):
Am Thu, 13 May 2021 13:11:10 +0100
schrieb Andrew Cooper :
> If I'm counting bits correctly, that is Xen rejecting the use of the NX
> bit, which is suspicious.
I tried 'dom0=pvh,debug':
...
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) Running stub recovery selftests...
(XEN) Fi
On 13/05/2021 13:22, Olaf Hering wrote:
> Am Thu, 13 May 2021 13:11:10 +0100
> schrieb Andrew Cooper :
>
>> If I'm counting bits correctly, that is Xen rejecting the use of the NX
>> bit, which is suspicious. Do you have the full Xen boot log on this
>> box? I wonder if we've some problem clobbin
Am Thu, 13 May 2021 13:11:10 +0100
schrieb Andrew Cooper :
> If I'm counting bits correctly, that is Xen rejecting the use of the NX
> bit, which is suspicious. Do you have the full Xen boot log on this
> box? I wonder if we've some problem clobbing the XD-disable bit.
Yes, it was attached.
Is
On 13/05/2021 11:24, Olaf Hering wrote:
> Recent pvops dom0 kernels fail to boot on this particular ProLiant BL465c G5
> box.
> It happens to work with every Xen and a 4.4 based sle12sp3 kernel, but fails
> with every Xen and a 4.12 based sle12sp4 (and every newer) kernel.
>
> Any idea what is go
Le 13/05/2021 à 12:03, Juergen Gross a écrit :
Xen frontends shouldn't BUG() in case of illegal data received from
their backends. So replace the BUG_ON()s when reading illegal data from
the ring page with negative return values.
Signed-off-by: Juergen Gross
---
drivers/tty/hvc/hvc_xen.c |
On 13.05.21 12:25, Greg Kroah-Hartman wrote:
On Thu, May 13, 2021 at 12:03:02PM +0200, Juergen Gross wrote:
Xen frontends shouldn't BUG() in case of illegal data received from
their backends. So replace the BUG_ON()s when reading illegal data from
the ring page with negative return values.
Sign
On Thu, May 13, 2021 at 12:03:02PM +0200, Juergen Gross wrote:
> Xen frontends shouldn't BUG() in case of illegal data received from
> their backends. So replace the BUG_ON()s when reading illegal data from
> the ring page with negative return values.
>
> Signed-off-by: Juergen Gross
> ---
> dri
Recent pvops dom0 kernels fail to boot on this particular ProLiant BL465c G5
box.
It happens to work with every Xen and a 4.4 based sle12sp3 kernel, but fails
with every Xen and a 4.12 based sle12sp4 (and every newer) kernel.
Any idea what is going on?
(XEN) Freed 256kB init memory.
(XEN)
On 13.05.21 12:16, Christophe Leroy wrote:
Le 13/05/2021 à 12:03, Juergen Gross a écrit :
Xen frontends shouldn't BUG() in case of illegal data received from
their backends. So replace the BUG_ON()s when reading illegal data from
the ring page with negative return values.
Signed-off-by: Juerg
Xen frontends shouldn't BUG() in case of illegal data received from
their backends. So replace the BUG_ON()s when reading illegal data from
the ring page with negative return values.
Signed-off-by: Juergen Gross
---
drivers/tty/hvc/hvc_xen.c | 15 +--
1 file changed, 13 insertions(+)
In order to avoid problems in case the backend is modifying a response
on the ring page while the frontend has already seen it, just read the
response into a local buffer in one go and then operate on that buffer
only.
Signed-off-by: Juergen Gross
---
drivers/net/xen-netfront.c | 38
Today blkfront will trust the backend to send only sane response data.
In order to avoid privilege escalations or crashes in case of malicious
backends verify the data to be within expected limits. Especially make
sure that the response always references an outstanding request.
Introduce a new sta
Today netfront will trust the backend to send only sane response data.
In order to avoid privilege escalations or crashes in case of malicious
backends verify the data to be within expected limits. Especially make
sure that the response always references an outstanding request.
Note that only the
In order to avoid a malicious backend being able to influence the local
copy of a request build the request locally first and then copy it to
the ring page instead of doing it the other way round as today.
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkfront.c | 25 +++
Sync include/xen/interface/io/ring.h with Xen's newest version in
order to get the RING_COPY_RESPONSE() and RING_RESPONSE_PROD_OVERFLOW()
macros.
Note that this will correct the wrong license info by adding the
missing original copyright notice.
Signed-off-by: Juergen Gross
---
include/xen/inte
In order to avoid problems in case the backend is modifying a response
on the ring page while the frontend has already seen it, just read the
response into a local buffer in one go and then operate on that buffer
only.
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkfront.c | 35 ++
Xen backends of para-virtualized devices can live in dom0 kernel, dom0
user land, or in a driver domain. This means that a backend might
reside in a less trusted environment than the Xen core components, so
a backend should not be able to do harm to a Xen guest (it can still
mess up I/O data, but i
In order to avoid a malicious backend being able to influence the local
processing of a request build the request locally first and then copy
it to the ring page. Any reading from the request needs to be done on
the local instance.
Signed-off-by: Juergen Gross
---
drivers/net/xen-netfront.c | 75
Am Thu, 13 May 2021 11:49:58 +0200
schrieb Roger Pau Monné :
> Can you boot with dom0=msr-relaxed on the Xen command line?
Yes, that helps - I just discovered this cmdline option.
Olaf
pgprxX69rpcQm.pgp
Description: Digitale Signatur von OpenPGP
On Thu, May 13, 2021 at 11:21:36AM +0200, Olaf Hering wrote:
> I have access to a ProLiant BL465c G5, which can boot a xenlinux based dom0
> kernel, like the one included in SLE11SP4. But it fails to do that with
> staging-4.15 and staging:
>
> ...
> [0.197199] node 0 link 0: io port [1000,
I have access to a ProLiant BL465c G5, which can boot a xenlinux based dom0
kernel, like the one included in SLE11SP4. But it fails to do that with
staging-4.15 and staging:
...
[0.197199] node 0 link 0: io port [1000, 3fff]
[0.197199] node 0 link 2: io port [4000, ]
(XEN) emul-priv-
On 13/05/2021 09:03, Anastasiia Lukianenko wrote:
Hi all,
Hi,
The problem described below concerns cases when a shared info page
needs to be handed over from one entity in the system to another, for
example, there is a bootloader or any other code that may run before
the guest OS' kernel.
Am Thu, 13 May 2021 08:03:48 +
schrieb Anastasiia Lukianenko :
> shared info page needs to be handed over from one entity in the system to
> another
The same issue exists with kexec. Not sure why it was not addressed as you
proposed, "soft_reset" was implemented instead.
Good luck.
Olaf
flight 161918 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161918/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 161832
test-amd64-i386-xl-qemut-win7-amd64 19
Hi all,
The problem described below concerns cases when a shared info page
needs to be handed over from one entity in the system to another, for
example, there is a bootloader or any other code that may run before
the guest OS' kernel.
Normally, to map the shared info page guests allocate a memory
flight 161927 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161927/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
64 matches
Mail list logo
