The XS_INTRODUCE command has two parameters: the mfn (or better: gfn)
of the domain's xenstore ring page and the event channel of the
domain for communicating with Xenstore.
The gfn is not really needed. It is stored in the per-domain struct
in xenstored and in case of another XS_INTRODUCE for
flight 149878 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149878/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-stop fail REGR. vs. 149749
Tests which did not succeed,
On Wed, 15 Apr 2020, Jan Beulich wrote:
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2527,6 +2527,7 @@ int __init construct_dom0(struct domain *d)
> >
> > iommu_hwdom_init(d);
> >
> > +d->arch.direct_map = true;
>
> Shouldn't this get set via
On Wed, 15 Apr 2020, Jan Beulich wrote:
> On 15.04.2020 03:02, Stefano Stabellini wrote:
> > We are passing an extra special boolean flag at domain creation to
> > specify whether we want to the domain to be privileged (i.e. dom0) or
> > not. Another flag will be introduced later in this series.
>
flight 149877 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149877/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 149866
flight 149884 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149884/
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
On Fri, 17 Apr 2020, Jan Beulich wrote:
> On 15.04.2020 03:02, Stefano Stabellini wrote:
> > --- a/xen/common/page_alloc.c
> > +++ b/xen/common/page_alloc.c
> > @@ -911,54 +911,18 @@ static struct page_info *get_free_buddy(unsigned int
> > zone_lo,
> > }
> > }
> >
> > -/* Allocate
Hey all,
We're looking to develop UEFI Secure Boot support for grub-loaded Xen and
ultimately for XCP-ng (I'm on the XCP-ng team at Vates).
In addition to carrying the chain-of-trust through the entire boot sequence
into dom0, we would also like to build something akin to Linux's Lockdown for
On Fri, 17 Apr 2020, Jan Beulich wrote:
> On 15.04.2020 03:02, Stefano Stabellini wrote:
> > Introduce a function named reserve_heap_pages (similar to
> > alloc_heap_pages) that allocates a requested memory range. Call
> > __alloc_heap_pages for the implementation.
> >
> > Change
On Wed, 15 Apr 2020, Julien Grall wrote:
> Hi Stefano,
>
> On 15/04/2020 02:02, Stefano Stabellini wrote:
> > If xen_force (which means xen,force-assign-without-iommu was requested)
> > don't try to add the device to the IOMMU. Return early instead.
>
>
> Could you explain why this is an issue
Older binutils complains with:
trampoline.S:95: Error: junk `ul&0x' after expression
Use an assembly-safe constant.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/include/asm-x86/processor.h | 2 +-
1 file changed, 1 insertion(+), 1
On Wed, 15 Apr 2020, Julien Grall wrote:
> On 15/04/2020 02:02, Stefano Stabellini wrote:
> > iomem_permit_access should be called for MMIO regions of devices
> > assigned to a domain. Currently it is not called for MMIO regions of
> > passthrough devices of Dom0less guests. This patch fixes it.
>
flight 149883 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149883/
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
On Thu, 16 Apr 2020, Julien Grall wrote:
> > Stefano Stabellini (12):
> >xen: introduce xen_dom_flags
> >xen/arm: introduce arch_xen_dom_flags and direct_map
> >xen/arm: introduce 1:1 mapping for domUs
> >xen: split alloc_heap_pages in two halves for reusability
> >
flight 149875 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149875/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 141899
flight 149876 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149876/
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
In Credit2, the CPUs are assigned to runqueues according to the host
topology. For instance, if we want per-socket runqueues (which is the
default), the CPUs that are in the same socket will end up in the same
runqueue.
This is generally good for scalability, at least until the number of
CPUs
Just move the big if() condition in an inline function.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched/credit2.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git
When doing an assisted flush on HAP the purpose of the
on_selected_cpus is just to trigger a vmexit on remote CPUs that are
in guest context, and hence just using is_vcpu_dirty_cpu is too lax,
also check that the vCPU is running.
While there also pass NULL as the data parameter of
In Credit2 CPUs (can) share runqueues, depending on the topology. For
instance, with per-socket runqueues (the default) all the CPUs that are
part of the same socket share a runqueue.
On platform with a huge number of CPUs per socket, that could be a
problem. An example is AMD EPYC2 servers,
Awesome, thanks!
On Wed, Apr 29, 2020 at 10:55 PM Andrew Cooper
wrote:
> On 29/04/2020 18:17, Ayush Dosaj wrote:
> > Hi Xen development team,
> >
> > I am Ayush. I compiled Xen Hypervisor from source on Ubuntu 20.04
> > machine running on an intel-i9 CPU.
> > I am getting compilation error due
On 29/04/2020 18:17, Ayush Dosaj wrote:
> Hi Xen development team,
>
> I am Ayush. I compiled Xen Hypervisor from source on Ubuntu 20.04
> machine running on an intel-i9 CPU.
> I am getting compilation error due to the following two flags.
> Error: error: ‘-mindirect-branch’ and ‘-fcf-protection’
Hi Xen development team,
I am Ayush. I compiled Xen Hypervisor from source on Ubuntu 20.04 machine
running on an intel-i9 CPU.
I am getting compilation error due to the following two flags.
Error: error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible.
Complete Error logs can be
On Wed, Apr 29, 2020 at 06:08:01PM +0200, David Hildenbrand wrote:
> We soon want to pass flags - prepare for that.
>
> This patch is based on a similar patch by Oscar Salvador:
>
> https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
>
[...]
> ---
> drivers/hv/hv_balloon.c
flight 149871 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149871/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 149865
Tests which did not
We don't want /sys/firmware/memmap entries and we want to indicate
our memory as "System RAM (driver managed)" in /proc/iomem. This is
especially relevant for kexec-tools, which have to be updated to
support dumping virtio-mem memory after this patch. Expected behavior in
kexec-tools:
- Don't use
This series is based on [1]:
[PATCH v2 00/10] virtio-mem: paravirtualized memory
That will hopefull get picked up soon, rebased to -next.
The following patches were reverted from -next [2]:
[PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use
As discussed in that
Some paravirtualized devices that add memory via add_memory() and
friends (esp. virtio-mem) don't want to create entries in
/sys/firmware/memmap/ - primarily to hinder kexec from adding this
memory to the boot memmap of the kexec kernel.
In fact, such memory is never exposed via the firmware
We soon want to pass flags - prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Greg
On 29.04.2020 17:30, Julien Grall wrote:
> Hi Jan,
>
> On 29/04/2020 16:23, Jan Beulich wrote:
>> On 29.04.2020 17:06, Julien Grall wrote:
>>>
>>>
>>> On 29/04/2020 15:56, Jan Beulich wrote:
On 29.04.2020 16:14, Julien Grall wrote:
> Hi Jan,
>
> On 29/04/2020 15:05, Jan Beulich
Hi Jan,
On 29/04/2020 16:23, Jan Beulich wrote:
On 29.04.2020 17:06, Julien Grall wrote:
On 29/04/2020 15:56, Jan Beulich wrote:
On 29.04.2020 16:14, Julien Grall wrote:
Hi Jan,
On 29/04/2020 15:05, Jan Beulich wrote:
On 29.04.2020 16:01, Julien Grall wrote:
Hi,
On 22/04/2020 10:20,
On 29.04.2020 17:06, Julien Grall wrote:
>
>
> On 29/04/2020 15:56, Jan Beulich wrote:
>> On 29.04.2020 16:14, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 29/04/2020 15:05, Jan Beulich wrote:
On 29.04.2020 16:01, Julien Grall wrote:
> Hi,
>
> On 22/04/2020 10:20, Jan Beulich
On 29/04/2020 15:56, Jan Beulich wrote:
On 29.04.2020 16:14, Julien Grall wrote:
Hi Jan,
On 29/04/2020 15:05, Jan Beulich wrote:
On 29.04.2020 16:01, Julien Grall wrote:
Hi,
On 22/04/2020 10:20, Jan Beulich wrote:
Even if it was possible to use the sub-structs defined in the header
that
On 07.04.2020 19:38, Paul Durrant wrote:
> +int main(int argc, char **argv)
> +{
> +uint32_t domid;
> +unsigned int entry;
> +xc_interface *xch;
> +int rc;
> +
> +if ( argc != 2 || !argv[1] || (rc = atoi(argv[1])) < 0 )
> +{
> +fprintf(stderr, "usage: %s \n",
On 29/04/2020 15:54, Jan Beulich wrote:
On 29.04.2020 16:13, Julien Grall wrote:
So can you please have another and explain how the line can be drawn with just
two architectures in place.
There are abstract considerations that can be used to draw the
line, as well as knowledge of people
On 29.04.2020 15:58, Hongyan Xia wrote:
> From: Wei Liu
>
> Also, clean up the initialisation of plXe.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
On 29.04.2020 16:14, Julien Grall wrote:
> Hi Jan,
>
> On 29/04/2020 15:05, Jan Beulich wrote:
>> On 29.04.2020 16:01, Julien Grall wrote:
>>> Hi,
>>>
>>> On 22/04/2020 10:20, Jan Beulich wrote:
> Even if it was possible to use the sub-structs defined in the header
> that way, keep in
On 29.04.2020 16:13, Julien Grall wrote:
> So can you please have another and explain how the line can be drawn with
> just two architectures in place.
There are abstract considerations that can be used to draw the
line, as well as knowledge of people on architectures Xen doesn't
run on, but
On 07.04.2020 19:38, Paul Durrant wrote:
> @@ -358,6 +359,113 @@ static struct vnuma_info *vnuma_init(const struct
> xen_domctl_vnuma *uinfo,
> return ERR_PTR(ret);
> }
>
> +struct domctl_context
> +{
> +void *buffer;
> +size_t len;
> +size_t cur;
> +};
> +
> +static int
On 29/04/2020 15:11, Jan Beulich wrote:
> With the max base leaf using 0, this one should be using the extended
> leaf counterpart thereof, rather than some arbitrary extended leaf.
>
> Fixes: 588a966a572e ("libx86: Introduce x86_cpu_policies_are_compatible()")
> Signed-off-by: Jan Beulich
Hi Jan,
On 29/04/2020 15:05, Jan Beulich wrote:
On 29.04.2020 16:01, Julien Grall wrote:
Hi,
On 22/04/2020 10:20, Jan Beulich wrote:
Even if it was possible to use the sub-structs defined in the header
that way, keep in mind that we also wrote:
/* dummy member to force
Hi,
On 29/04/2020 15:07, Jan Beulich wrote:
On 29.04.2020 16:04, Julien Grall wrote:
Gentle ping. Any comments on the direction to take?
Just to avoid misunderstanding - while the mail was sent with me as
the only one on the To list, I don't think I've been meant, as I've
voiced my opinion.
With the max base leaf using 0, this one should be using the extended
leaf counterpart thereof, rather than some arbitrary extended leaf.
Fixes: 588a966a572e ("libx86: Introduce x86_cpu_policies_are_compatible()")
Signed-off-by: Jan Beulich
--- a/tools/tests/cpu-policy/test-cpu-policy.c
+++
On 29.04.2020 16:04, Julien Grall wrote:
> Gentle ping. Any comments on the direction to take?
Just to avoid misunderstanding - while the mail was sent with me as
the only one on the To list, I don't think I've been meant, as I've
voiced my opinion. I assume you rather meant to ping others to
Hi,
Gentle ping. Any comments on the direction to take?
On 09/04/2020 10:28, Julien Grall wrote:
On 09/04/2020 09:06, Jan Beulich wrote:
On 09.04.2020 10:01, Julien Grall wrote:
Hi,
On 09/04/2020 07:30, Jan Beulich wrote:
On 09.04.2020 00:05, Julien Grall wrote:
I don't see why a new
On 29.04.2020 16:01, Julien Grall wrote:
> Hi,
>
> On 22/04/2020 10:20, Jan Beulich wrote:
>>> Even if it was possible to use the sub-structs defined in the header
>>> that way, keep in mind that we also wrote:
>>>
>>> /* dummy member to force sizeof(struct xen_pvcalls_request)
>>>
Hi,
On 22/04/2020 10:20, Jan Beulich wrote:
Even if it was possible to use the sub-structs defined in the header
that way, keep in mind that we also wrote:
/* dummy member to force sizeof(struct xen_pvcalls_request)
* to match across archs */
struct
From: Wei Liu
Also, clean up the initialisation of plXe.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
Changed since last revision:
- lift this patch out since others in the series have been merged.
- remove lXt variables and reuse plXe for unmapping.
- clean up plXe initialisation.
On 29.04.2020 15:06, Andrew Cooper wrote:
> This is the start of some performance and security-hardening improvements,
> based on the fact that 32bit PV guests are few and far between these days.
>
> Ring1 is full of architectural corner cases, such as counting as supervisor
> from a paging point
flight 149874 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149874/
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
On 29.04.2020 15:36, Andrew Cooper wrote:
> On 29/04/2020 14:25, Jan Beulich wrote:
>> On 29.04.2020 13:32, Andrew Cooper wrote:
>>> On 29/04/2020 12:16, Jan Beulich wrote:
On 29.04.2020 13:09, Andrew Cooper wrote:
> --- a/xen/arch/x86/boot/trampoline.S
> +++
On 29/04/2020 14:06, Jürgen Groß wrote:
> On 29.04.20 14:49, Igor Druzhinin wrote:
>> On 29/04/2020 13:29, Jürgen Groß wrote:
>>> On 29.04.20 13:04, Igor Druzhinin wrote:
>>
>> Yes, XAPI is doing soft reset differently from libxl. You need to keep
>> xenstore
>> data to at least keep backends
On 29.04.2020 15:30, Andrew Cooper wrote:
> On 29/04/2020 14:29, Jan Beulich wrote:
>> On 29.04.2020 15:13, Andrew Cooper wrote:
>>> On 20/04/2020 15:09, Jan Beulich wrote:
On 17.04.2020 17:50, Andrew Cooper wrote:
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
On 29/04/2020 14:25, Jan Beulich wrote:
> On 29.04.2020 13:32, Andrew Cooper wrote:
>> On 29/04/2020 12:16, Jan Beulich wrote:
>>> On 29.04.2020 13:09, Andrew Cooper wrote:
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -91,6 +91,11 @@
On 29.04.2020 14:29, Hongyan Xia wrote:
> (Looks like other patches in this series have been merged. Replying to
> this one only.)
Please send as a proper patch, this one came through ...
> From: Wei Liu
> Date: Tue, 5 Feb 2019 16:32:54 +
> Subject: [PATCH] x86/pv: map and unmap page tables
On 29/04/2020 14:29, Jan Beulich wrote:
> On 29.04.2020 15:13, Andrew Cooper wrote:
>> On 20/04/2020 15:09, Jan Beulich wrote:
>>> On 17.04.2020 17:50, Andrew Cooper wrote:
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -215,7 +215,7 @@ int switch_compat(struct
On 29.04.2020 15:13, Andrew Cooper wrote:
> On 20/04/2020 15:09, Jan Beulich wrote:
>> On 17.04.2020 17:50, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/pv/domain.c
>>> +++ b/xen/arch/x86/pv/domain.c
>>> @@ -215,7 +215,7 @@ int switch_compat(struct domain *d)
>>> return 0;
>>>
>>>
On 29.04.2020 13:32, Andrew Cooper wrote:
> On 29/04/2020 12:16, Jan Beulich wrote:
>> On 29.04.2020 13:09, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/boot/trampoline.S
>>> +++ b/xen/arch/x86/boot/trampoline.S
>>> @@ -91,6 +91,11 @@ trampoline_protmode_entry:
>>> and %edi,%edx
>>>
On 29/04/2020 14:22, Paul Durrant wrote:
>> -Original Message-
>> From: Igor Druzhinin
>> Sent: 29 April 2020 14:17
>> To: p...@xen.org; 'Jürgen Groß' ; 'Julien Grall'
>> ; 'Julien Grall'
>>
>> Cc: 'xen-devel' ; 'Ian Jackson'
>> ; 'Wei Liu'
>> ; andrew.coop...@citrix.com
>> Subject:
Hi,
On 22/04/2020 10:32, Jan Beulich wrote:
On 22.04.2020 10:17, Julien Grall wrote:
On 21/04/2020 10:13, Jan Beulich wrote:
First of all avoid excessive conversions. copy_{from,to}_guest(), for
example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
Further
- do_physdev_op_compat()
On Fri, Apr 24, 2020 at 3:40 AM Paul Durrant wrote:
> * Linux stub domains (v4)
> - Marek Marczykowski-Górecki
In coordination with Marek, I've posted v5.
-Jason
> -Original Message-
> From: Igor Druzhinin
> Sent: 29 April 2020 14:17
> To: p...@xen.org; 'Jürgen Groß' ; 'Julien Grall'
> ; 'Julien Grall'
>
> Cc: 'xen-devel' ; 'Ian Jackson'
> ; 'Wei Liu'
> ; andrew.coop...@citrix.com
> Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of
On 29/04/2020 13:56, Paul Durrant wrote:
>> -Original Message-
>> From: Igor Druzhinin
>> Sent: 29 April 2020 13:50
>> To: Jürgen Groß ; Julien Grall ; Julien
>> Grall
>>
>> Cc: xen-devel ; Ian Jackson
>> ; Wei Liu
>> ; andrew.coop...@citrix.com; Paul Durrant
>> Subject: Re: [PATCH]
On 20/04/2020 15:09, Jan Beulich wrote:
> On 17.04.2020 17:50, Andrew Cooper wrote:
>> --- a/xen/arch/x86/pv/domain.c
>> +++ b/xen/arch/x86/pv/domain.c
>> @@ -215,7 +215,7 @@ int switch_compat(struct domain *d)
>> return 0;
>>
>> d->arch.has_32bit_shinfo = 1;
>> -
This is the start of some performance and security-hardening improvements,
based on the fact that 32bit PV guests are few and far between these days.
Ring1 is full of architectural corner cases, such as counting as supervisor
from a paging point of view. This accounts for a substantial
On 29.04.20 14:49, Igor Druzhinin wrote:
On 29/04/2020 13:29, Jürgen Groß wrote:
On 29.04.20 13:04, Igor Druzhinin wrote:
On 29/04/2020 11:49, Jürgen Groß wrote:
On 29.04.20 12:39, Igor Druzhinin wrote:
On 29/04/2020 10:22, Julien Grall wrote:
Hi Juergen,
On 29/04/2020 06:51, Jürgen Groß
> -Original Message-
> From: Igor Druzhinin
> Sent: 29 April 2020 13:50
> To: Jürgen Groß ; Julien Grall ; Julien Grall
>
> Cc: xen-devel ; Ian Jackson
> ; Wei Liu
> ; andrew.coop...@citrix.com; Paul Durrant
> Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
On 29/04/2020 13:29, Jürgen Groß wrote:
> On 29.04.20 13:04, Igor Druzhinin wrote:
>> On 29/04/2020 11:49, Jürgen Groß wrote:
>>> On 29.04.20 12:39, Igor Druzhinin wrote:
On 29/04/2020 10:22, Julien Grall wrote:
> Hi Juergen,
>
> On 29/04/2020 06:51, Jürgen Groß wrote:
>>
On 28/04/2020 12:55, Andrew Cooper wrote:
>> Below is what I was preparing to submit as a patch. So, yes it hacks around
>> it, but it isn't messy.
>>
>> ---
>> Disable fcf-protection to build working binaries
>>
>> Ubuntu gcc-9 enables -fcf-protection by default, which conflicts with
>>
On 29.04.20 13:04, Igor Druzhinin wrote:
On 29/04/2020 11:49, Jürgen Groß wrote:
On 29.04.20 12:39, Igor Druzhinin wrote:
On 29/04/2020 10:22, Julien Grall wrote:
Hi Juergen,
On 29/04/2020 06:51, Jürgen Groß wrote:
Recreating the event channel would be fine, but I don't see why it
would
(Looks like other patches in this series have been merged. Replying to
this one only.)
From: Wei Liu
Date: Tue, 5 Feb 2019 16:32:54 +
Subject: [PATCH] x86/pv: map and unmap page tables in
mark_pv_pt_pages_rdonly
Also, clean up the initialisation of plXe.
Signed-off-by: Wei Liu
On Wed, Apr 29, 2020 at 11:41:44AM +0100, Wei Liu wrote:
> The value returned from CPUID is the maximum number for virtual
> processors supported by Hyper-V. It could be larger than the maximum
> number of virtual processors configured.
>
> Stash the configured number into a variable and use it
flight 149868 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149868/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 17 guest-saverestore.2 fail REGR. vs. 149854
Tests which did not
On 29/04/2020 12:16, Jan Beulich wrote:
> On 29.04.2020 13:09, Andrew Cooper wrote:
>> --- a/xen/arch/x86/boot/trampoline.S
>> +++ b/xen/arch/x86/boot/trampoline.S
>> @@ -91,6 +91,11 @@ trampoline_protmode_entry:
>> and %edi,%edx
>> wrmsr
>> 1:
>> +/* Set up PAT
On 29.04.2020 13:09, Andrew Cooper wrote:
> --- a/xen/arch/x86/boot/trampoline.S
> +++ b/xen/arch/x86/boot/trampoline.S
> @@ -91,6 +91,11 @@ trampoline_protmode_entry:
> and %edi,%edx
> wrmsr
> 1:
> +/* Set up PAT before enabling paging. */
> +mov
There is no need to save/restore FS/GS/XCR0 state. It will be handled
suitably on the context switch away from the idle.
The CR4 restoration in restore_rest_processor_state() was actually fighting
later code in enter_state() which tried to keep CR4.MCE clear until everything
was set up. Delete
Hi Paul,
On 28/04/2020 16:35, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 20 April 2020 18:21
To: Paul Durrant ; xen-devel@lists.xenproject.org
Cc: Paul Durrant ; Andrew Cooper
; George Dunlap
; Ian Jackson ; Jan Beulich
;
Stefano Stabellini ; Wei Liu ; Volodymyr
On 29/04/2020 11:49, Jürgen Groß wrote:
> On 29.04.20 12:39, Igor Druzhinin wrote:
>> On 29/04/2020 10:22, Julien Grall wrote:
>>> Hi Juergen,
>>>
>>> On 29/04/2020 06:51, Jürgen Groß wrote:
Recreating the event channel would be fine, but I don't see why it
would ever be needed. And
On 29.04.2020 11:26, Hongyan Xia wrote:
> But if people do not have a problem with plXe - 1, I will post a new
> revision for that.
I'd prefer that; I could live with the current version, but I'm
not in favor of it.
Jan
On 07.04.2020 19:38, Paul Durrant wrote:
> +void __init domain_register_save_type(unsigned int tc, const char *name,
> + bool per_vcpu,
> + domain_save_handler save,
> +
On 29.04.20 12:39, Igor Druzhinin wrote:
On 29/04/2020 10:22, Julien Grall wrote:
Hi Juergen,
On 29/04/2020 06:51, Jürgen Groß wrote:
Recreating the event channel would be fine, but I don't see why it
would ever be needed. And XS_INTRODUCE is called only at domain creation
time today, so
The value returned from CPUID is the maximum number for virtual
processors supported by Hyper-V. It could be larger than the maximum
number of virtual processors configured.
Stash the configured number into a variable and use it in calculations.
Signed-off-by: Wei Liu
---
On 29/04/2020 10:22, Julien Grall wrote:
> Hi Juergen,
>
> On 29/04/2020 06:51, Jürgen Groß wrote:
>>
>> Recreating the event channel would be fine, but I don't see why it
>> would ever be needed. And XS_INTRODUCE is called only at domain creation
>> time today, so there is obviously no need for
flight 149872 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149872/
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
flight 149873 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149873/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6
baseline version:
xen
On Tue, 2020-04-28 at 16:59 +0100, Hongyan Xia wrote:
> On Tue, 2020-04-28 at 16:55 +0100, Hongyan Xia wrote:
> > On Tue, 2020-04-28 at 17:33 +0200, Jan Beulich wrote:
> > > On 17.04.2020 11:52, Hongyan Xia wrote:
> > > > --- a/xen/arch/x86/pv/dom0_build.c
> > > > +++
Hi Juergen,
On 29/04/2020 06:51, Jürgen Groß wrote:
On 28.04.20 22:55, Julien Grall wrote:
Hi Juergen,
On Tue, 28 Apr 2020 at 16:53, Juergen Gross wrote:
The XS_INTRODUCE command has two parameters: the mfn (or better: gfn)
of the domain's xenstore ring page and the event channel of the
On 29/04/2020 09:09, Jürgen Groß wrote:
> On 27.04.20 15:49, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> When I'm testing vcpu pinning with something like:
>>
>> # xl vcpu-pin 0 0 2
>> # xen-hptool cpu-offline 3
>>
>> (offline / online CPUs {2,3} if the above is successful)
>>
>>
On Wed, Apr 29, 2020 at 10:35:24AM +0200, Jan Beulich wrote:
> On 29.04.2020 10:26, Roger Pau Monné wrote:
> > On Wed, Apr 29, 2020 at 09:37:11AM +0200, Jan Beulich wrote:
> >> On 28.04.2020 18:14, Roger Pau Monné wrote:
> >>> On Tue, Apr 28, 2020 at 02:21:48PM +0200, Jan Beulich wrote:
>
On 29.04.2020 10:26, Roger Pau Monné wrote:
> On Wed, Apr 29, 2020 at 09:37:11AM +0200, Jan Beulich wrote:
>> On 28.04.2020 18:14, Roger Pau Monné wrote:
>>> On Tue, Apr 28, 2020 at 02:21:48PM +0200, Jan Beulich wrote:
XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTs.
flight 149869 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149869/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b2034179e8feed9c7d3bc8f9d40a18fd236c5b57
baseline version:
ovmf
The XS_INTRODUCE command has two parameters: the mfn (or better: gfn)
of the domain's xenstore ring page and the event channel of the
domain for communicating with Xenstore.
The gfn is not really needed. It is stored in the per-domain struct
in xenstored and in case of another XS_INTRODUCE for
On Wed, Apr 29, 2020 at 09:37:11AM +0200, Jan Beulich wrote:
> On 28.04.2020 18:14, Roger Pau Monné wrote:
> > On Tue, Apr 28, 2020 at 02:21:48PM +0200, Jan Beulich wrote:
> >> XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTs.
> >> In that scenario, it is possible to
On 02.04.2020 16:25, Andrew Cooper wrote:
> On 09/03/2020 09:08, Jan Beulich wrote:
>> Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
>>
>> There have been reports of RDRAND issues after resuming from suspend on
>> some AMD family 15h and family 16h systems. This issue
> -Original Message-
> From: Grzegorz Uriasz
> Sent: 29 April 2020 04:04
> To: qemu-de...@nongnu.org
> Cc: Grzegorz Uriasz ; marma...@invisiblethingslab.com;
> ar...@puzio.waw.pl;
> ja...@bartmin.ski; j.nowa...@student.uw.edu.pl; Stefano Stabellini
> ; Anthony
> Perard ; Paul Durrant ;
On 27.04.20 15:49, Sergey Dyasli wrote:
Hi Juergen,
When I'm testing vcpu pinning with something like:
# xl vcpu-pin 0 0 2
# xen-hptool cpu-offline 3
(offline / online CPUs {2,3} if the above is successful)
I'm reliably seeing the following crash on the latest staging:
On Tue, Apr 28, 2020 at 08:29:00AM -0700, Tamas K Lengyel wrote:
> During a VM fork we copy the shared_info page; however, we also need to ensure
> that the page is mapped into the same GFN in the fork as its in the parent.
>
> Signed-off-by: Tamas K Lengyel
> Suggested-by: Roger Pau Monne
> -Original Message-
> From: Grzegorz Uriasz
> Sent: 29 April 2020 04:04
> To: qemu-de...@nongnu.org
> Cc: Grzegorz Uriasz ; marma...@invisiblethingslab.com;
> ar...@puzio.waw.pl;
> ja...@bartmin.ski; j.nowa...@student.uw.edu.pl; Stefano Stabellini
> ; Anthony
> Perard ; Paul Durrant ;
On 28.04.2020 18:14, Roger Pau Monné wrote:
> On Tue, Apr 28, 2020 at 02:21:48PM +0200, Jan Beulich wrote:
>> XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTs.
>> In that scenario, it is possible to receive multiple _pirq_guest_unbind
>> calls for the same pirq from
flight 149870 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149870/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
1 - 100 of 103 matches
Mail list logo
