flight 156825 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156825/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 16.11.2020 22:57, Cheyenne Wills wrote:
> Running Xen with XSA-351 is causing Solaris 11 systems to panic during
> boot. The panic screen is showing the failure to be coming from
> "unix:rdmsr". The panic occurs with existing guests (booting off a disk)
> and the booting from an install ISO i
On 16.11.20 17:28, Andy Lutomirski wrote:
On Mon, Nov 16, 2020 at 7:23 AM Juergen Gross wrote:
USERGS_SYSRET64 is used to return from a syscall via sysret, but
a Xen PV guest will nevertheless use the iret hypercall, as there
is no sysret PV hypercall defined.
So instead of testing all the pr
On Mon, Nov 16, 2020 at 07:22:11PM +0100, Manuel Bouyer wrote:
> On Sun, Nov 15, 2020 at 07:24:16PM +0100, Roger Pau Monné wrote:
> > On Sun, Nov 15, 2020 at 06:49:38PM +0100, Manuel Bouyer wrote:
> > > Hello,
> > > I spent some more time debugging NetBSD as a PVH dom0 on Xen,
> > > With Roger's pa
On Tue, Nov 17, 2020 at 10:02:04AM +0100, Roger Pau Monné wrote:
> Great! So all interrupts are working as expected now?
No, I'm back at the problem where the PERC raid controller times out on
commands. I'm cleaing up my sources and will try to get more data
about this problem.
--
Manuel Bouyer
Fix the command line document to account for the default scheduler in
Kconfig being credit2 now, and the fact that it's selectable at build
time and thus different builds could end up with different default
schedulers.
Fixes: dafd936dddbd ('Make credit2 the default scheduler')
Signed-off-by: Roger
Olaf reported observing
xenstat_qmp.c:26:10: fatal error: _paths.h: No such file or directory
.../tools/libs/stat/../../../tools/Rules.mk:153: xenstat_qmp.opic] Error 1
Obviously _paths.h, when included by any of the sources, needs to be
created in advance of compiling any of them, not just the n
On Tue, Nov 17, 2020 at 10:07:33AM +0100, Manuel Bouyer wrote:
> On Tue, Nov 17, 2020 at 10:02:04AM +0100, Roger Pau Monné wrote:
> > Great! So all interrupts are working as expected now?
>
> No, I'm back at the problem where the PERC raid controller times out on
> commands. I'm cleaing up my sour
Hello Stefano,
> On 17 Nov 2020, at 1:20 am, Stefano Stabellini wrote:
>
> On Mon, 16 Nov 2020, Rahul Singh wrote:
>> passthrough/pci.c file is common for all architecture, but there is x86
>> specific code in this file.
>>
>> Move x86 specific code to the drivers/passthrough/io.c file to avoid
flight 156829 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156829/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 29d59baa3907277782e9f26ecaa99704ff57e3f1
baseline version:
ovmf 124b3f9289f11479d9f04
On Mon, Nov 16, 2020 at 04:22:57PM +0100, Juergen Gross wrote:
> Eliminate the usergs_sysret64 paravirt call completely and switch
> the swapgs one to use ALTERNATIVE instead. This requires to fix the
> IST based exception entries for Xen PV to use the same mechanism as
> NMI and debug exception al
On Tue, Nov 17, 2020 at 10:45:34AM +0100, Roger Pau Monné wrote:
> On Tue, Nov 17, 2020 at 10:07:33AM +0100, Manuel Bouyer wrote:
> > On Tue, Nov 17, 2020 at 10:02:04AM +0100, Roger Pau Monné wrote:
> > > Great! So all interrupts are working as expected now?
> >
> > No, I'm back at the problem whe
On Mon, Nov 16, 2020 at 02:57:14PM -0700, Cheyenne Wills wrote:
> Running Xen with XSA-351 is causing Solaris 11 systems to panic during
> boot. The panic screen is showing the failure to be coming from
> "unix:rdmsr". The panic occurs with existing guests (booting off a disk)
> and the booting
On 16.11.2020 13:25, Rahul Singh wrote:
> NS16550 driver has PCI support that is under HAS_PCI flag. When HAS_PCI
> is enabled for ARM, compilation error is observed for ARM architecture
> because ARM platforms do not have full PCI support available.
While you've extended the sentence, it remains
On 16.11.2020 13:25, Rahul Singh wrote:
> passthrough/pci.c file is common for all architecture, but there is x86
> specific code in this file.
In how far is ...
> @@ -1370,13 +1301,6 @@ static int __init setup_dump_pcidevs(void)
> }
> __initcall(setup_dump_pcidevs);
>
> -int iommu_update_ire
On 16.11.2020 13:25, Rahul Singh wrote:
> If mem-sharing, mem-paging, or log-dirty functionality is not enabled
> for non-x86 architecture when HAS_PCI is enabled, the compiler will
> throw an error.
>
> Move code to x86 specific directory to fix compilation error.
Perhaps rather "file" than "dir
On 26.10.2020 10:13, Juergen Gross wrote:
> @@ -15,10 +29,7 @@ struct hypfs_entry {
> unsigned int max_size;
> const char *name;
> struct list_head list;
> -int (*read)(const struct hypfs_entry *entry,
> -XEN_GUEST_HANDLE_PARAM(void) uaddr);
> -int (*write)(st
On 26.10.2020 10:13, Juergen Gross wrote:
> Instead of handling all errors from hypfs_get_entry() as ENOENT pass
> up the real error value via ERR_PTR().
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
On 26.10.2020 10:13, Juergen Gross wrote:
> Add a getsize() function pointer to struct hypfs_funcs for being able
> to have dynamically filled entries without the need to take the hypfs
> lock each time the contents are being generated.
But a dynamic update causing a change in size will require _s
On Tue, Nov 17, 2020 at 11:50:39AM +0100, Roger Pau Monné wrote:
> On Mon, Nov 16, 2020 at 02:57:14PM -0700, Cheyenne Wills wrote:
> > Running Xen with XSA-351 is causing Solaris 11 systems to panic during
> > boot. The panic screen is showing the failure to be coming from
> > "unix:rdmsr". The p
On 26.10.2020 10:13, Juergen Gross wrote:
> --- a/xen/common/hypfs.c
> +++ b/xen/common/hypfs.c
> @@ -257,6 +257,82 @@ unsigned int hypfs_getsize(const struct hypfs_entry
> *entry)
> return entry->size;
> }
>
> +int hypfs_read_dyndir_id_entry(struct hypfs_entry_dir *template,
> +
Yes. I will have to re-upgrade my xen system to collect the additional info
from the panic, so it will be later today before I can reply with all the
info.
On Tue, Nov 17, 2020, 5:54 AM Roger Pau Monné wrote:
> On Tue, Nov 17, 2020 at 11:50:39AM +0100, Roger Pau Monné wrote:
> > On Mon, Nov 16,
flight 156827 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156827/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64 20 guest-start/debianhvm.repeat fail
pass in 156814
test-armhf-armhf
On 26.10.2020 10:13, Juergen Gross wrote:
> @@ -992,6 +994,78 @@ static struct notifier_block cpu_nfb = {
> .notifier_call = cpu_callback
> };
>
> +#ifdef CONFIG_HYPFS
> +static HYPFS_DIR_INIT(cpupool_pooldir, "id");
This "id" string won't appear anywhere, will it? I would have
expected th
On 17.11.20 12:18, Jan Beulich wrote:
On 26.10.2020 10:13, Juergen Gross wrote:
@@ -15,10 +29,7 @@ struct hypfs_entry {
unsigned int max_size;
const char *name;
struct list_head list;
-int (*read)(const struct hypfs_entry *entry,
-XEN_GUEST_HANDLE_PARAM(void
On 17.11.20 13:37, Jan Beulich wrote:
On 26.10.2020 10:13, Juergen Gross wrote:
Add a getsize() function pointer to struct hypfs_funcs for being able
to have dynamically filled entries without the need to take the hypfs
lock each time the contents are being generated.
But a dynamic update caus
On 17.11.20 14:33, Jan Beulich wrote:
On 26.10.2020 10:13, Juergen Gross wrote:
--- a/xen/common/hypfs.c
+++ b/xen/common/hypfs.c
@@ -257,6 +257,82 @@ unsigned int hypfs_getsize(const struct hypfs_entry *entry)
return entry->size;
}
+int hypfs_read_dyndir_id_entry(struct hypfs_entry_d
On 17.11.2020 15:29, Jürgen Groß wrote:
> On 17.11.20 13:37, Jan Beulich wrote:
>> On 26.10.2020 10:13, Juergen Gross wrote:
>>> --- a/xen/common/hypfs.c
>>> +++ b/xen/common/hypfs.c
>>> @@ -19,28 +19,29 @@
>>> CHECK_hypfs_dirlistentry;
>>> #endif
>>>
>>> -#define DIRENTRY_NAME_OFF offsetof(
The Solaris version reported in the copyright banner on the ISO is SunOS
Release 5.11 Version 11.4.0.15.0 64-bit
My existing guest solaris systems are also at the same release/version level
At the time of the panic, the panic log reports that the rcx register
contains '0606' (this was from my not
On 17/11/2020 14:43, Cheyenne Wills wrote:
> The Solaris version reported in the copyright banner on the ISO is
> SunOS Release 5.11 Version 11.4.0.15.0 64-bit
>
> My existing guest solaris systems are also at the same release/version
> level
>
> At the time of the panic, the panic log reports that
Hi Paul
The 'legacy' mechanism of mapping magic pages for ioreq servers
should remain x86 specific I think that aspect of the code needs to
remain behind and not get moved into common code. You could do that
in arch specific calls in hvm_ioreq_server_enable/disable() and
hvm_get_ioreq_ser
On 17.11.2020 15:38, Jürgen Groß wrote:
> On 17.11.20 14:33, Jan Beulich wrote:
>> On 26.10.2020 10:13, Juergen Gross wrote:
>>> +static struct hypfs_entry *hypfs_dyndir_findentry(struct hypfs_entry_dir
>>> *dir,
>>> + const char *name,
>>> +
On 17.11.20 15:13, Jan Beulich wrote:
On 26.10.2020 10:13, Juergen Gross wrote:
@@ -992,6 +994,78 @@ static struct notifier_block cpu_nfb = {
.notifier_call = cpu_callback
};
+#ifdef CONFIG_HYPFS
+static HYPFS_DIR_INIT(cpupool_pooldir, "id");
This "id" string won't appear anywhere,
On 17.11.20 15:40, Jan Beulich wrote:
On 17.11.2020 15:29, Jürgen Groß wrote:
On 17.11.20 13:37, Jan Beulich wrote:
On 26.10.2020 10:13, Juergen Gross wrote:
--- a/xen/common/hypfs.c
+++ b/xen/common/hypfs.c
@@ -19,28 +19,29 @@
CHECK_hypfs_dirlistentry;
#endif
-#define DIRENTRY_NAME_
Hello,
so, after fixing an issue in the NetBSD kernel, related to PV clock
interrupts, I'm back with physical interrupts issues.
At some point in the initialisation, the dom0 kernel stops receiving
interrupts for its disks controller. The disk controller is:
[ 1.030] mfii0 at pci6 dev 0 funct
On 17.11.20 15:50, Jan Beulich wrote:
On 17.11.2020 15:38, Jürgen Groß wrote:
On 17.11.20 14:33, Jan Beulich wrote:
On 26.10.2020 10:13, Juergen Gross wrote:
+static struct hypfs_entry *hypfs_dyndir_findentry(struct hypfs_entry_dir *dir,
+ const
> -Original Message-
> From: Oleksandr
> Sent: 17 November 2020 14:48
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Oleksandr Tyshchenko'
> ; 'Andrew
> Cooper' ; 'George Dunlap'
> ; 'Ian Jackson'
> ; 'Jan Beulich' ; 'Julien Grall'
> ; 'Stefano
> Stabellini' ; 'Wei Liu' ; 'Ro
On Tue, Nov 17, 2020 at 04:09:49PM +0100, Manuel Bouyer wrote:
> Hello,
> so, after fixing an issue in the NetBSD kernel, related to PV clock
> interrupts, I'm back with physical interrupts issues.
> At some point in the initialisation, the dom0 kernel stops receiving
> interrupts for its disks con
Hello Jan,
> On 17 Nov 2020, at 11:12 am, Jan Beulich wrote:
>
> On 16.11.2020 13:25, Rahul Singh wrote:
>> If mem-sharing, mem-paging, or log-dirty functionality is not enabled
>> for non-x86 architecture when HAS_PCI is enabled, the compiler will
>> throw an error.
>>
>> Move code to x86 spec
On 17.11.20 17:29, Paul Durrant wrote:
Hi Paul
Thank you for the prompt answer.
The 'legacy' mechanism of mapping magic pages for ioreq servers
should remain x86 specific I think that aspect of the code needs to
remain behind and not get moved into common code. You could do that
in arch spec
On Tue, Nov 17, 2020 at 04:58:07PM +0100, Roger Pau Monné wrote:
> [...]
>
> I have attached a patch below that will dump the vIO-APIC info as part
> of the 'i' debug key output, can you paste the whole output of the 'i'
> debug key when the system stalls?
see attached file. Note that the kernel
On 26.10.2020 10:13, Juergen Gross wrote:
> @@ -1057,6 +1063,43 @@ static struct hypfs_entry
> *cpupool_dir_findentry(struct hypfs_entry_dir *dir,
> return hypfs_gen_dyndir_entry_id(&cpupool_pooldir, id);
> }
>
> +static int cpupool_gran_read(const struct hypfs_entry *entry,
> +
Hello Jan,
> On 17 Nov 2020, at 11:03 am, Jan Beulich wrote:
>
> On 16.11.2020 13:25, Rahul Singh wrote:
>> passthrough/pci.c file is common for all architecture, but there is x86
>> specific code in this file.
>
> In how far is ...
>
>> @@ -1370,13 +1301,6 @@ static int __init setup_dump_pcid
On 17.11.20 17:49, Jan Beulich wrote:
On 26.10.2020 10:13, Juergen Gross wrote:
@@ -1057,6 +1063,43 @@ static struct hypfs_entry *cpupool_dir_findentry(struct
hypfs_entry_dir *dir,
return hypfs_gen_dyndir_entry_id(&cpupool_pooldir, id);
}
+static int cpupool_gran_read(const struct hy
Hi Michal,
On 16/11/2020 12:11, Michal Orzel wrote:
On the affected Cortex-A76/Neoverse-N1 cores (r0p0 to r3p0),
if a virtual address for a cacheable mapping of a location is being
accessed by a core while another core is remapping the virtual
address to a new physical page using the recommended
Hi,
On 09/11/2020 16:38, Juergen Gross wrote:
The patches for XSA-343 produced some fallout, especially the event
channel locking has shown to be problematic.
Patch 1 is targeting fifo event channels for avoiding any races for the
case that the fifo queue has been changed for a specific event c
Signed-off-by: Edwin Török
---
automation/build/ubuntu/focal.dockerfile | 50
automation/scripts/containerize | 1 +
2 files changed, 51 insertions(+)
create mode 100644 automation/build/ubuntu/focal.dockerfile
diff --git a/automation/build/ubuntu/focal.docker
On CentOS 8 with SELinux containerize doesn't work at all:
Make sure that the source code and SSH agent directories are passed on
with SELinux relabeling enabled.
(`-security-opt label=disabled` would be another option)
Signed-off-by: Edwin Török
---
automation/scripts/containerize | 6 +++---
The xl toolstack allows some control over the domid at VM creation time,
allow xenopsd similar control by exposing the appropriate domid field in the
OCaml xenctrl bindings.
A new API function is introduced to preserve backwards compatibility without
merge ordering
requirements between the Xen an
As a convenience so that oxenstored patches can be compile-tested
using upstream's build-system before submitting upstream.
Signed-off-by: Edwin Török
---
Makefile | 6 ++
tools/ocaml/Makefile | 8
2 files changed, 14 insertions(+)
diff --git a/Makefile b/Makefile
index
One can specify the domid to use when creating the domain, but this was
hardcoded to 0.
Keep the existing `domain_create` function (and the type of its parameters) as
is to make
backwards compatibility easier.
Introduce a new `domain_create_domid` OCaml API that allows specifying the
domid.
A n
flight 156832 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156832/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
> -Original Message-
[snip]
>
> Both hvm_ioreq_server_init() and hvm_ioreq_server_deinit() call "legacy"
> hvm_ioreq_server_unmap_pages()
> which we want to be abstracted. The only difference between these two
> usages is that the former calls it during rollback only (in case of error).
>
flight 156831 qemu-mainline real [real]
flight 156837 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156831/
http://logs.test-lab.xenproject.org/osstest/logs/156837/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
> -Original Message-
> From: Oleksandr Andrushchenko
> Sent: 16 November 2020 10:34
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Anthony PERARD
> ; Christian Lindig
> ; David Scott ; George Dunlap
> ; Ian Jackson ; Nick Rosbrook
> ;
> Wei Liu
> Subject: Re: [
Is anyone else looking at vmlinuz files which use zstd compression? Fedora
has started doing so with its 5.9 kernels.
Michael Young
On 17/11/2020 20:27, Michael Young wrote:
> Is anyone else looking at vmlinuz files which use zstd compression?
> Fedora has started doing so with its 5.9 kernels.
Well volunteered ;)
Yes - I'm aware that it is an area needing working on, but it is not
sufficiently urgent on my TODO stack to look
flight 156838 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156838/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e6a12a0fc817e26ac05e8301e89433c2367ff362
baseline version:
ovmf 29d59baa3907277782e9f
Adding Bertrand, Oleksandr, Julien, and others -- they have a more
recent experience with GICv3 ITS than me and might be able to help.
I am attaching the device tree Leo sent a few days ago for reference.
Typically when you can set the ethernet link up and no packets are
exchanged it is because o
From: Stefano Stabellini
A recent thread [1] has exposed a couple of issues with our current way
of handling EXPERT.
1) It is not obvious that "Configure standard Xen features (expert
users)" is actually the famous EXPERT we keep talking about on xen-devel
2) It is not obvious when we need to e
On Tue, Nov 17, 2020 at 08:48:25PM +, Andrew Cooper wrote:
> For domU's, tools/libs/guest/xg_dom_bzimageloader.c and
> xc_dom_probe_bzimage_kernel()
>
> (Wow this plumbing is ugly and in need of some rationalisation...)
Though not part of Xen, the PV part of grub could also do with some
love
Hi Julien,
On 17.11.2020 18:30, Julien Grall wrote:
> Hi Michal,
>
> On 16/11/2020 12:11, Michal Orzel wrote:
>> On the affected Cortex-A76/Neoverse-N1 cores (r0p0 to r3p0),
>> if a virtual address for a cacheable mapping of a location is being
>> accessed by a core while another core is remappin
flight 156841 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156841/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 18.11.20 08:26, osstest service owner wrote:
flight 156841 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156841/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-insta
flight 156840 qemu-mainline real [real]
flight 156850 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156840/
http://logs.test-lab.xenproject.org/osstest/logs/156850/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
65 matches
Mail list logo
