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, too.
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 st
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 ch
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.
Signed
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 info
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
build-arm64-
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 func
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
test-amd64-i386-xl
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
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, J
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
test-amd64-i386-xl-qemu
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
build-arm64-
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 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 mig
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 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
build-arm64-
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 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 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
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
build-arm64-
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
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 Marczykowski-Górecki
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 then
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 n
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 1
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
>>>
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
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 the
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 onl
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 paramete
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 convention
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 explaina
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 libxl__cpuid_apply_policy(
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
Xen-devel@lists.xenproject.org
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 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 f
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 scann
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
> current
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 in
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 co
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 activated
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 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 P
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 @@ static
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 identi
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 conditio
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, 0x7ff0
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 comb
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
xenstore:
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 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 cr
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, 18
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 {
> > >
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 Cooper
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 (*e820_fix
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 Eikelenbo
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 gu
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
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 gue
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 +++
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 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
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
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
test-amd64-i386-xl
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) C
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 re
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, c
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 re
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
https://lis
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 a/xe
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] current=d[IDLE]v1
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 introd
> -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 unneces
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 up/do
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 +0
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 +0
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
>>> situa
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
f855dd962523b6cb47a92037bdd28
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 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
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 o
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 no
> -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
>
> Ad
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.
>
> I'
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
--
Dar
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 b/xen/common
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. :
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 b
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.
Unfortu
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 ("xe
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 dr
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 a
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
___
Xen-dev
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 and
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 failu
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
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
99 matches
Mail list logo
