On 11.02.20 21:18, Andrew Cooper wrote:
On 28/01/2020 14:28, Juergen Gross wrote:
In order to be able to get access to the console of Xenstore stubdom
we need an appropriate granttab entry. So call xc_dom_gnttab_init()
when constructing the domain and preset some information needed
for that
flight 146859 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146859/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 134708
test-arm64-arm64-xl-xsm 13
flight 146909 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146909/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
flight 146899 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146899/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
flight 146858 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146858/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 20 guest-start/debian.repeat fail REGR. vs. 142947
build-amd64
flight 146886 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146886/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
flight 146860 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146860/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 139698
build-i386
flight 146876 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146876/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
146121
In order to be able to get access to the console of Xenstore stubdom
we need an appropriate granttab entry. So call xc_dom_gnttab_init()
when constructing the domain and preset some information needed
for that function in the dom structure.
We need to create the event channel for the console,
In order to be able to connect to the console of Xenstore stubdom we
need to create the appropriate entries in Xenstore.
For the moment we don't support xenconsoled living in another domain
than dom0, as this information isn't available other then via
Xenstore which we are just setting up.
When run in a stubdom environment Xenstore can't select a logfile or
emit memory statistics to a specific file.
So remove or modify those control commands accordingly.
Signed-off-by: Juergen Gross
Acked-by: Andrew Cooper
---
tools/xenstore/xenstored_control.c | 18 ++
1 file
Some patches for Xenstore-stubdom which have been lying around in my
local tree for some time now.
Juergen Gross (3):
xenstore: setup xenstore stubdom console interface properly
xenstore: add console xenstore entries for xenstore stubdom
xenstore: remove not applicable control commands in
February 11, 2020 9:09 PM, "Marek Marczykowski-Górecki"
wrote:
> On Tue, Feb 11, 2020 at 12:59:22PM +, Claudia wrote:
>
>> February 10, 2020 12:14 PM, "Marek Marczykowski-Górecki"
>> wrote:
>>
>> On Mon, Feb 10, 2020 at 11:17:34AM +, Andrew Cooper wrote:
>>
>> On 10/02/2020 08:55,
flight 146892 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146892/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
On 11.02.20 21:25, Andrew Cooper wrote:
On 28/01/2020 14:28, Juergen Gross wrote:
In order to be able to connect to the console of Xenstore stubdom we
need to create the appropriate entries in Xenstore.
For the moment we don't support xenconsoled living in another domain
than dom0, as this
flight 146918 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146918/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
On 11.02.20 10:29, Dario Faggioli wrote:
On Mon, 2020-02-10 at 17:45 +0100, Juergen Gross wrote:
The ASSERT() at the top of csched2_context_saved() is completely
pointless, as the BUG_ON() just in front of it catches the same
problem
already.
Yep, I went double checking and this is my fault.
flight 146839 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146839/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 146787
Tests which did
On 11.02.2020 11:29, Tamas K Lengyel wrote:
> On Tue, Feb 11, 2020 at 2:17 AM Jan Beulich wrote:
>>
>> On 10.02.2020 20:21, Tamas K Lengyel wrote:
>>> The owner domain of shared pages is dom_cow, use that for get_page
>>> otherwise the function fails to return the correct page under some
>>>
On Mon, 2020-02-10 at 17:45 +0100, Juergen Gross wrote:
> The ASSERT() at the top of csched2_context_saved() is completely
> pointless, as the BUG_ON() just in front of it catches the same
> problem
> already.
>
Yep, I went double checking and this is my fault. :-(
Apparently, in ccf2ead7f52
Conform to style, drop unnecessary local variables, and avoid opencoding
clear_domain_page().
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
Avoiding opencoding clear_domain_page() drops a surprising quantity of code.
add/remove: 0/0 grow/shrink: 0/3
On Tue, Feb 11, 2020 at 11:19:02AM +, Anthony PERARD wrote:
> On Mon, Jan 27, 2020 at 02:40:40PM +, Wei Liu wrote:
> > On Mon, Jan 27, 2020 at 12:36:23PM +, Anthony PERARD wrote:
> > > On Mon, Jan 27, 2020 at 12:30:21PM +, Wei Liu wrote:
> > > > On Mon, Jan 20, 2020 at 11:52:17AM
On 10.02.2020 18:33, Andrew Cooper wrote:
> The MMIO registers as already byte offsets. Using them in this form removes
> the need to shift their values for use.
>
> It is also inefficient to store both entries and alloc_size (which only differ
> by entry_size). Rename alloc_size to size, and
With core scheduling active it is mandatory for stop_machine_run() to
be called in a tasklet only, as otherwise a scheduling deadlock would
occur: stop_machine_run() does a cpu rendezvous by activating a tasklet
on all other cpus. In case stop_machine_run() was not called in an idle
vcpu it would
On Tue, Feb 11, 2020 at 2:17 AM Jan Beulich wrote:
>
> On 10.02.2020 20:21, Tamas K Lengyel wrote:
> > The owner domain of shared pages is dom_cow, use that for get_page
> > otherwise the function fails to return the correct page under some
> > situations. The check if dom_cow should be used was
On Mon, Jan 27, 2020 at 02:40:40PM +, Wei Liu wrote:
> On Mon, Jan 27, 2020 at 12:36:23PM +, Anthony PERARD wrote:
> > On Mon, Jan 27, 2020 at 12:30:21PM +, Wei Liu wrote:
> > > On Mon, Jan 20, 2020 at 11:52:17AM +, Anthony PERARD wrote:
> > > > On Mon, Jan 20, 2020 at 11:50:50AM
On 07/02/2020 08:04, Jürgen Groß wrote:
> On 06.02.20 15:02, Sergey Dyasli wrote:
>> On 06/02/2020 11:05, Sergey Dyasli wrote:
>>> On 06/02/2020 09:57, Jürgen Groß wrote:
On 05.02.20 17:03, Sergey Dyasli wrote:
> Hello,
>
> I'm currently investigating a Live-Patch application
flight 146841 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146841/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
build-i386
On 10.02.2020 20:21, Tamas K Lengyel wrote:
> The owner domain of shared pages is dom_cow, use that for get_page
> otherwise the function fails to return the correct page under some
> situations. The check if dom_cow should be used was only performed in
> a subset of use-cases. Fixing the error
The BUG_ON() at the top of csched2_context_saved() is completely
pointless, as the ASSERT() just following it catches the same problem
already.
Signed-off-by: Juergen Gross
---
xen/common/sched/credit2.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/common/sched/credit2.c
On 11.02.20 11:37, Dario Faggioli wrote:
On Mon, 2020-02-10 at 16:39 +0100, Juergen Gross wrote:
sched_init_pdata() is used nowhere, it can be removed. Same applies
to
the .init_pdata hook of the per-scheduler interface.
Right, and that appear to be the case since
On Mon, 2020-02-10 at 16:39 +0100, Juergen Gross wrote:
> sched_init_pdata() is used nowhere, it can be removed. Same applies
> to
> the .init_pdata hook of the per-scheduler interface.
>
Right, and that appear to be the case since
f855dd962523b6cb47a92037bdd28b1485141abe ("sched: add minimalistic
On 10.02.2020 21:09, Wei Liu wrote:
> On Mon, Feb 10, 2020 at 06:39:21PM +, Andrew Cooper wrote:
>> Fixes: b25fb1a04e "xen/pvh: Fix segment selector ABI"
>> Signed-off-by: Andrew Cooper
>
> Reviewed-by: Wei Liu
Acked-by: Jan Beulich
___
On 11.02.20 10:07, Sergey Dyasli wrote:
On 07/02/2020 08:04, Jürgen Groß wrote:
On 06.02.20 15:02, Sergey Dyasli wrote:
On 06/02/2020 11:05, Sergey Dyasli wrote:
On 06/02/2020 09:57, Jürgen Groß wrote:
On 05.02.20 17:03, Sergey Dyasli wrote:
Hello,
I'm currently investigating a Live-Patch
On Tue, 2020-02-11 at 10:36 +0100, Jürgen Groß wrote:
> On 11.02.20 10:29, Dario Faggioli wrote:
> >
> > TBH, though, considering the nature of the check, I'd rather keep
> > the
> > ASSERT() and kill the BUG_ON().
> >
> > I can do the patch myself if you don't want to respin it that way.
>
>
> -Original Message-
> From: Roger Pau Monne
> Sent: 10 February 2020 18:28
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Durrant, Paul
> ; Wei Liu ; Jan Beulich
> ; Andrew Cooper
> Subject: [PATCH v4 6/7] xen/guest: prepare hypervisor ops to use
> alternative calls
>
>
On Mon, Feb 10, 2020 at 06:28:29PM +0100, Roger Pau Monne wrote:
[...]
>
> struct hypervisor_ops {
> @@ -32,6 +34,8 @@ struct hypervisor_ops {
> void (*resume)(void);
> /* Fix up e820 map */
> void (*e820_fixup)(struct e820map *e820);
> +/* L0 assisted TLB flush */
> +int
flight 146843 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146843/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 146182
build-arm64-libvirt
One of the main design goals of core scheduling is to avoid actions
which are not directly related to the domain currently running on a
given cpu or core. Live patching is one of those actions which are
allowed taking place on a cpu only when the idle scheduling unit is
active on that cpu.
On Tue, 2020-02-11 at 10:44 +0100, Juergen Gross wrote:
> The BUG_ON() at the top of csched2_context_saved() is completely
> pointless, as the ASSERT() just following it catches the same problem
> already.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Thanks and Regards
--
sched_init_pdata() is used nowhere, it can be removed. Same applies to
the .init_pdata hook of the per-scheduler interface. The last caller
has been removed with commit f855dd962523b6cb47a92037bdd28b1485141abe
("sched: add minimalistic idle scheduler for free cpus").
With the idle scheduler
On 11/02/2020 13:39, Andrew Cooper wrote:
> Ballooning inside PV shim is currently very broken.
>
> From an instrumented Xen and 32bit PV XTF test:
>
> (d3) (d3) --- Xen Test Framework ---
> (d3) (d3) Ballooning: PV 32bit (PAE 3 levels)
> (d3) (d3) mr { 0010a940, 1024, 0x7ff0 }
> (d3) (d3) About
> -Original Message-
> From: Xen-devel On Behalf Of
> Andrew Cooper
> Sent: 11 February 2020 12:27
> To: Xen-devel
> Cc: Andrew Cooper ; Wei Liu ; Jan
> Beulich ; Roger Pau Monné
> Subject: [Xen-devel] [PATCH] AMD/IOMMU: Clean up the allocation helpers
>
> Conform to style, drop
Ballooning inside PV shim is currently very broken.
From an instrumented Xen and 32bit PV XTF test:
(d3) (d3) --- Xen Test Framework ---
(d3) (d3) Ballooning: PV 32bit (PAE 3 levels)
(d3) (d3) mr { 0010a940, 1024, 0x7ff0 }
(d3) (d3) About to decrease
(d3) (XEN) *** D { 82008020, nr 1020,
On Mon, Feb 10, 2020 at 09:49:30PM +0100, Sander Eikelenboom wrote:
> On 03/02/2020 14:21, Roger Pau Monné wrote:
> > On Mon, Feb 03, 2020 at 01:44:06PM +0100, Sander Eikelenboom wrote:
> >> On 03/02/2020 13:41, Roger Pau Monné wrote:
> >>> On Mon, Feb 03, 2020 at 01:30:55PM +0100, Sander
On 11/02/2020 12:37, Juergen Gross wrote:
> softirq_init() is empty since Sen 4.1. Remove it together with its call
> sites.
>
> Signed-off-by: Juergen Gross
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 11.02.20 14:01, Jan Beulich wrote:
On 11.02.2020 13:27, Juergen Gross wrote:
When dumping the run queue information add some more data regarding
current and (if known) previous vcpu for each physical cpu.
With core scheduling activated the printed data will be e.g.:
(XEN) CPUs info:
(XEN)
Hide the following information that can help identify the running Xen
binary version: XENVER_[extraversion|compile_info|changeset]
This makes harder for malicious guests to fingerprint Xen to identify
exploitable systems.
Introduce xsm_filter_denied() to hvmloader to remove "" string
from guest's
Add Kconfig option to make it possible to configure the string returned
to non-privileged guests instead of the default "" which could
propagate to UI / logs after the subsequent patch that hides detailed
Xen version information from unprivileged guests.
Introduce XENVER_denied_string to allow
Now a proper 2 patches series.
Sergey Dyasli (2):
xsm: add Kconfig option for denied string
xsm: hide detailed Xen version from unprivileged guests
tools/firmware/hvmloader/hvmloader.c | 1 +
tools/firmware/hvmloader/smbios.c| 1 +
tools/firmware/hvmloader/util.c | 11 +++
On 11/02/2020 13:42, Sergey Dyasli wrote:
> Add Kconfig option to make it possible to configure the string returned
> to non-privileged guests instead of the default "" which could
> propagate to UI / logs after the subsequent patch that hides detailed
> Xen version information from unprivileged
The printf() in init_hypercalls() only ends up in the hypervisor console log,
so extraversion really isn't interesting.
The SMBios table doesn't need extraversion, and removing it reduces the
ability for a guest to fingerprint the exact hypervisor it is running under.
Signed-off-by: Andrew
softirq_init() is empty since Sen 4.1. Remove it together with its call
sites.
Signed-off-by: Juergen Gross
---
xen/arch/arm/setup.c | 2 --
xen/arch/x86/setup.c | 1 -
xen/common/softirq.c | 4
xen/include/xen/softirq.h | 1 -
4 files changed, 8 deletions(-)
diff --git
On 11.02.2020 13:27, Juergen Gross wrote:
> When dumping the run queue information add some more data regarding
> current and (if known) previous vcpu for each physical cpu.
>
> With core scheduling activated the printed data will be e.g.:
>
> (XEN) CPUs info:
> (XEN) CPU[00] current=d[IDLE]v0,
On Tue, Feb 11, 2020 at 4:04 AM Jan Beulich wrote:
>
> On 11.02.2020 11:29, Tamas K Lengyel wrote:
> > On Tue, Feb 11, 2020 at 2:17 AM Jan Beulich wrote:
> >>
> >> On 10.02.2020 20:21, Tamas K Lengyel wrote:
> >>> The owner domain of shared pages is dom_cow, use that for get_page
> >>> otherwise
On Tue, Feb 11, 2020 at 03:06:21PM +0100, Roger Pau Monné wrote:
> On Tue, Feb 11, 2020 at 10:34:24AM +, Wei Liu wrote:
> > On Mon, Feb 10, 2020 at 06:28:29PM +0100, Roger Pau Monne wrote:
> > [...]
> > >
> > > struct hypervisor_ops {
> > > @@ -32,6 +34,8 @@ struct hypervisor_ops {
> > >
When dumping the run queue information add some more data regarding
current and (if known) previous vcpu for each physical cpu.
With core scheduling activated the printed data will be e.g.:
(XEN) CPUs info:
(XEN) CPU[00] current=d[IDLE]v0, curr=d[IDLE]v0, prev=NULL
(XEN) CPU[01]
flight 146842 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146842/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
146121
flight 146844 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146844/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
On Tue, Feb 11, 2020 at 10:34:24AM +, Wei Liu wrote:
> On Mon, Feb 10, 2020 at 06:28:29PM +0100, Roger Pau Monne wrote:
> [...]
> >
> > struct hypervisor_ops {
> > @@ -32,6 +34,8 @@ struct hypervisor_ops {
> > void (*resume)(void);
> > /* Fix up e820 map */
> > void
FYI, If you have voted in private for this (by replying directly to Lars),
you'll need to re-send your vote to
(which is currently being redirected to Ian Jackson and myself).
-George
On Fri, Jan 17, 2020 at 7:13 PM Lars Kurth wrote:
> I propose to tally the votes after March 31st. You can
February 10, 2020 12:14 PM, "Marek Marczykowski-Górecki"
wrote:
> On Mon, Feb 10, 2020 at 11:17:34AM +, Andrew Cooper wrote:
>
>> On 10/02/2020 08:55, Jan Beulich wrote:
>> On 10.02.2020 00:06, Marek Marczykowski-Górecki wrote:
>> Hi,
>>
>> Multiple Qubes users have reported issues with
On 28.01.20 15:28, Juergen Gross wrote:
Some patches for Xenstore-stubdom which have been lying around in my
local tree for some time now.
Juergen Gross (3):
xenstore: setup xenstore stubdom console interface properly
xenstore: add console xenstore entries for xenstore stubdom
On 11.02.20 17:46, Jan Beulich wrote:
On 11.02.2020 14:10, Jürgen Groß wrote:
On 11.02.20 14:01, Jan Beulich wrote:
On 11.02.2020 13:27, Juergen Gross wrote:
When dumping the run queue information add some more data regarding
current and (if known) previous vcpu for each physical cpu.
With
flight 146846 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146846/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
build-i386
On 11.02.2020 17:31, Roger Pau Monné wrote:
> On Tue, Feb 11, 2020 at 03:51:54PM +, Andrew Cooper wrote:
>> Currently when booting native on AMD hardware, cpuidmask_defaults._1cd gets
>> configured with the HYPERVISOR bit before native CPUID is scanned for feature
>> bits.
>>
>> This results
> On Jan 27, 2020, at 2:12 PM, George Dunlap wrote:
>
> I have drafted an explicit policy on what is (generally) required to
> check a patch in. It's been through several rounds, and v4 has been
> acked [1].
>
> I've had informal assent from all committers, but just to dot all our
> i's and
These were introduced in 262bb227a4 in 2012, and have never had any users.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/drivers/passthrough/amd/iommu-defs.h | 5 -
xen/drivers/passthrough/amd/iommu.h | 13 -
2 files changed,
On Tue, Feb 11, 2020 at 01:39:42PM +, Andrew Cooper wrote:
> Ballooning inside PV shim is currently very broken.
>
> From an instrumented Xen and 32bit PV XTF test:
>
> (d3) (d3) --- Xen Test Framework ---
> (d3) (d3) Ballooning: PV 32bit (PAE 3 levels)
> (d3) (d3) mr { 0010a940, 1024,
On Tue, Feb 11, 2020 at 03:51:54PM +, Andrew Cooper wrote:
> Currently when booting native on AMD hardware, cpuidmask_defaults._1cd gets
> configured with the HYPERVISOR bit before native CPUID is scanned for feature
> bits.
>
> This results in cpu_has_hypervisor becoming set as part of
flight 146871 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146871/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 146838
Tests which
On Tue, Feb 11, 2020 at 04:29:36PM +, Igor Druzhinin wrote:
> On 11/02/2020 16:01, Roger Pau Monné wrote:
> > On Tue, Feb 11, 2020 at 01:39:42PM +, Andrew Cooper wrote:
> >> Shim can't decrease reservation (HVM with L0 Xen) on any frame who's
> >> reference count didn't drop to 0 from the
On 11/02/2020 16:31, Roger Pau Monné wrote:
> On Tue, Feb 11, 2020 at 03:51:54PM +, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>> index 4fa9c91140..ce76d6d776 100644
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -48,7 +48,7 @@
On 11/02/2020 16:59, Jan Beulich wrote:
> On 11.02.2020 17:31, Roger Pau Monné wrote:
>> On Tue, Feb 11, 2020 at 03:51:54PM +, Andrew Cooper wrote:
>>> Currently when booting native on AMD hardware, cpuidmask_defaults._1cd gets
>>> configured with the HYPERVISOR bit before native CPUID is
Currently when booting native on AMD hardware, cpuidmask_defaults._1cd gets
configured with the HYPERVISOR bit before native CPUID is scanned for feature
bits.
This results in cpu_has_hypervisor becoming set as part of identify_cpu(), and
ends up appearing in the raw and host CPU policies.
A
On 11/02/2020 16:01, Roger Pau Monné wrote:
> On Tue, Feb 11, 2020 at 01:39:42PM +, Andrew Cooper wrote:
>> Shim can't decrease reservation (HVM with L0 Xen) on any frame who's
>> reference count didn't drop to 0 from the PV guests' call, and there is
>> nothing presently to check this
On 11.02.2020 14:10, Jürgen Groß wrote:
> On 11.02.20 14:01, Jan Beulich wrote:
>> On 11.02.2020 13:27, Juergen Gross wrote:
>>> When dumping the run queue information add some more data regarding
>>> current and (if known) previous vcpu for each physical cpu.
>>>
>>> With core scheduling
On 11.02.2020 17:54, Jürgen Groß wrote:
> On 11.02.20 17:46, Jan Beulich wrote:
>> On 11.02.2020 14:10, Jürgen Groß wrote:
>>> On 11.02.20 14:01, Jan Beulich wrote:
On 11.02.2020 13:27, Juergen Gross wrote:
> When dumping the run queue information add some more data regarding
>
Andrew Cooper writes ("[PATCH 4/6] tools/libxl: Combine legacy CPUID handling
logic"):
> While we are in the process of overhauling boot time CPUID/MSR handling, the
> existing logic is going to have to remain in roughly this form for backwards
> compatibility.
>
> Fold
Andrew Cooper writes ("[PATCH 5/6] tools/libx[cl]: Don't use
HVM_PARAM_PAE_ENABLED as a function parameter"):
> The sole use of HVM_PARAM_PAE_ENABLED is as a non-standard calling convention
> for xc_cpuid_apply_policy(). Pass PAE as a regular parameter instead.
>
> Leave a rather better
On 11/02/2020 17:47, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 5/6] tools/libx[cl]: Don't use
> HVM_PARAM_PAE_ENABLED as a function parameter"):
>> The sole use of HVM_PARAM_PAE_ENABLED is as a non-standard calling convention
>> for xc_cpuid_apply_policy(). Pass PAE as a regular
On 11/02/2020 18:11, Roger Pau Monné wrote:
> On Tue, Feb 11, 2020 at 05:29:09PM +, Igor Druzhinin wrote:
>> On 11/02/2020 16:42, Roger Pau Monné wrote:
>>> On Tue, Feb 11, 2020 at 04:29:36PM +, Igor Druzhinin wrote:
Agree. But as I said I'm not aware of any guest that violates the
On 11/02/2020 16:42, Roger Pau Monné wrote:
> On Tue, Feb 11, 2020 at 04:29:36PM +, Igor Druzhinin wrote:
>> Agree. But as I said I'm not aware of any guest that violates the
>> invariant of decrease_reservation() being the last call.
>
> Maybe we could piggyback on whether a page is removed
flight 146875 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146875/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
Andrew Cooper writes ("[PATCH 3/6] tools/python: Drop cpuid helpers"):
> These are believed-unused, and the underlying infrastructure is about to be
> rewritten completely.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Andrew Cooper writes ("[PATCH 6/6] xen/public: Obsolete HVM_PARAM_PAE_ENABLED"):
> HVM_PARAM_PAE_ENABLED is undocumented and Xen has never acted upon its value,
> contrary perhaps to expectations based on how other boolean fields work.
>
> It was only ever used as a non-standard calling
On 11/02/2020 17:49, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 6/6] xen/public: Obsolete
> HVM_PARAM_PAE_ENABLED"):
>> HVM_PARAM_PAE_ENABLED is undocumented and Xen has never acted upon its value,
>> contrary perhaps to expectations based on how other boolean fields work.
>>
>> It was
On Tue, Feb 11, 2020 at 05:29:09PM +, Igor Druzhinin wrote:
> On 11/02/2020 16:42, Roger Pau Monné wrote:
> > On Tue, Feb 11, 2020 at 04:29:36PM +, Igor Druzhinin wrote:
> >> Agree. But as I said I'm not aware of any guest that violates the
> >> invariant of decrease_reservation() being
flight 146882 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146882/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Andrew Cooper writes ("[PATCH 1/6] tools/libxl: Remove
libxl_cpuid_{set,apply_policy}() from the API"):
> These functions should never have been exposed. They don't have external
> users, and can't usefully be used for several reasons.
Acked-by: Ian Jackson
On 28/01/2020 14:28, Juergen Gross wrote:
> In order to be able to get access to the console of Xenstore stubdom
> we need an appropriate granttab entry. So call xc_dom_gnttab_init()
> when constructing the domain and preset some information needed
> for that function in the dom structure.
>
> We
On 28/01/2020 14:28, Juergen Gross wrote:
> When run in a stubdom environment Xenstore can't select a logfile or
> emit memory statistics to a specific file.
>
> So remove or modify those control commands accordingly.
>
> Signed-off-by: Juergen Gross
Acked-by: Andrew Cooper
On 28/01/2020 14:28, Juergen Gross wrote:
> In order to be able to connect to the console of Xenstore stubdom we
> need to create the appropriate entries in Xenstore.
>
> For the moment we don't support xenconsoled living in another domain
> than dom0, as this information isn't available other
On Tue, Feb 11, 2020 at 12:59:22PM +, Claudia wrote:
> February 10, 2020 12:14 PM, "Marek Marczykowski-Górecki"
> wrote:
>
> > On Mon, Feb 10, 2020 at 11:17:34AM +, Andrew Cooper wrote:
> >
> >> On 10/02/2020 08:55, Jan Beulich wrote:
> >> On 10.02.2020 00:06, Marek
flight 146848 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146848/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 146796
build-amd64
flight 146850 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146850/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 12 guest-start fail REGR. vs. 133580
build-i386-pvops
flight 146857 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146857/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-examine 8 reboot fail REGR. vs. 142849
test-armhf-armhf-xl
flight 146893 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146893/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
flight 146851 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146851/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 142932
Tests which did not
99 matches
Mail list logo
