On 24.01.2020 16:31, Paul Durrant wrote:
> ... to domain_relinquish_resources().
>
> The teardown code frees the APICv page. This does not need to be done late
> so do it in domain_relinquish_resources() rather than domain_destroy().
For the normal domain destruction path this is fine. For the er
> -Original Message-
> From: Jan Beulich
> Sent: 28 January 2020 08:15
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Jun Nakajima ;
> Kevin Tian ; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George Dunlap
> Subject: Re: [PATCH v4 4/7] x86 / vmx: move teardown from
> domai
On Wed, 22 Jan 2020 at 20:36, Andrew Cooper wrote:
>
> On 19/01/2020 06:17, Kevin Buckley wrote:
> > Any clues then, as to whether this is another Python3 hangover for Xen ?
>
> Xen 4.13 (now released) is the first version of Xen with any serious
> form Python 3 compatibility (and even then, we mi
It has become apparent to some large cloud providers that the current
model of cooperative migration of guests under Xen is not usable as it
relies on software running inside the guest, which is likely beyond the
provider's control.
This patch introduces a proposal for non-cooperative live migratio
On 27/01/2020 18:56, Igor Druzhinin wrote:
The existing RCU barrier implementation is prone to a deadlock scenario
due to IRQs being re-enabled inside stopmachine context. If due to a race
IRQs are re-enabled on some of CPUs and softirqs are allowed to be
processed in stopmachine, i.e. what cur
On Mon, Jan 27, 2020 at 08:43:21PM +, tosher 1 wrote:
> Rojer,
>
> > You can also start xl devd manually, as that will give you verbose
> > output of whats going on. In the driver domain:
>
> > # killall xl
> > # xl -vvv devd -F
>
> > That should give you detailed output of what's going on i
On Mon, Jan 27, 2020 at 08:21:21PM +, 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 Mon, Jan 27, 2020 at 09:29:16PM +, Igor Druzhinin wrote:
> ... and enable it after exiting S-state. Otherwise accumulated
> output in serial buffer might easily trigger the watchdog if it's
> still enabled after entering sync transmission mode.
Can't you just process the watchdog in serial_
On 28/01/2020 10:45, Roger Pau Monné wrote:
> On Mon, Jan 27, 2020 at 09:29:16PM +, Igor Druzhinin wrote:
>> ... and enable it after exiting S-state. Otherwise accumulated
>> output in serial buffer might easily trigger the watchdog if it's
>> still enabled after entering sync transmission mode
On 28/01/2020 10:39, Roger Pau Monné wrote:
>
>> This is one of two possible approaches, and both have their downsides. This
>> one takes an extra hit on context switches between PV vcpus and idle/hvm, as
>> they will usually differ in HYPERVISOR bit.
>>
>> The other approach is to order things mo
On Tue, Jan 28, 2020 at 10:55:00AM +, Igor Druzhinin wrote:
> On 28/01/2020 10:45, Roger Pau Monné wrote:
> > On Mon, Jan 27, 2020 at 09:29:16PM +, Igor Druzhinin wrote:
> >> ... and enable it after exiting S-state. Otherwise accumulated
> >> output in serial buffer might easily trigger the
On 28/01/2020 11:32, Roger Pau Monné wrote:
> On Tue, Jan 28, 2020 at 10:55:00AM +, Igor Druzhinin wrote:
>> On 28/01/2020 10:45, Roger Pau Monné wrote:
>>> On Mon, Jan 27, 2020 at 09:29:16PM +, Igor Druzhinin wrote:
... and enable it after exiting S-state. Otherwise accumulated
o
On 28.01.2020 09:22, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 28 January 2020 08:15
>> To: Durrant, Paul
>> Cc: xen-devel@lists.xenproject.org; Jun Nakajima ;
>> Kevin Tian ; Andrew Cooper
>> ; Wei Liu ; Roger Pau Monné
>> ; George Dunlap
>> Subject: Re: [
On 2020-01-28 05:58, Boqun Feng wrote:
On Fri, Jan 24, 2020 at 10:24:44AM +, Vincenzo Frascino wrote:
Hi Boqun Feng,
On 24/01/2020 06:32, Boqun Feng wrote:
> Hi Vincenzo,
>
[...]
>>
>> I had a look to your patches and overall, I could not understand why we can't
>> use the arch_timer to d
flight 146543 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146543/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 146534
test-amd64-amd64-xl-qemut-win7-amd64
On Tue, Jan 28, 2020 at 11:21:14AM +, Andrew Cooper wrote:
> On 28/01/2020 10:39, Roger Pau Monné wrote:
> >
> >> This is one of two possible approaches, and both have their downsides.
> >> This
> >> one takes an extra hit on context switches between PV vcpus and idle/hvm,
> >> as
> >> they
On 28/01/2020 11:58, Roger Pau Monné wrote:
> On Tue, Jan 28, 2020 at 11:21:14AM +, Andrew Cooper wrote:
>> On 28/01/2020 10:39, Roger Pau Monné wrote:
This is one of two possible approaches, and both have their downsides.
This
one takes an extra hit on context switches between
On Mon, 27 Jan 2020, Boris Ostrovsky wrote:
> RAX=0 most likely means that map->notifier is NULL (assuming your
> compiler generates code similar to mine).
>
> I believe you at least need
>
>
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 4fc83e3f..d35cf0b 100644
> --- a/dri
Patch #1 was standalone in v2 and is unmodified in v3.
Paul Durrant (2):
docs/designs: Add a design document for non-cooperative live migration
docs/designs: Add a design document for migration of xenstore data
docs/designs/non-cooperative-migration.md | 259 ++
docs/desi
This patch details proposes extra migration data and xenstore protocol
extensions to support non-cooperative live migration of guests.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano S
It has become apparent to some large cloud providers that the current
model of cooperative migration of guests under Xen is not usable as it
relies on software running inside the guest, which is likely beyond the
provider's control.
This patch introduces a proposal for non-cooperative live migratio
Note that the "LibxlFmt" in the stream should remain unchanged.
Signed-off-by: Wei Liu
---
docs/specs/libxl-migration-stream.pandoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/specs/libxl-migration-stream.pandoc
b/docs/specs/libxl-migration-stream.pandoc
index 3766f
On Mon, Jan 27, 2020 at 04:57:57PM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Ian Jackson
> > Sent: 27 January 2020 16:46
> > To: xen-devel@lists.xenproject.org
> > Cc: Durrant, Paul ; Ian Jackson
> > ; Wei Liu ; Andrew Cooper
> > ; George Dunlap ;
> > Jan Beulich ; Julie
On 28/01/2020 12:40, Wei Liu wrote:
> Note that the "LibxlFmt" in the stream should remain unchanged.
>
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/lis
flight 146544 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146544/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
test-amd64-amd64-xl-
boot_cpu_has(X86_FEATURE_X2APIC) doesn't need checking to interpret
APIC_BASE_EXTD.
Also take the opportunity to optimise the generated assembly by not using
rdmsrl(). GCC isn't clever enough to spot that it can drop the shift and or
to put %eax in the higher half of msr_contents.
No functional
On 27.01.2020 20:34, Eslam Elnikety wrote:
> On 23.01.20 11:26, Jan Beulich wrote:
>> On 22.01.2020 23:30, Eslam Elnikety wrote:
>>> Decouple the microcode indexing mechanism when using GRUB to that
>>> when using EFI. This allows us to avoid the "unspecified effect" of
>>> using `` when booting vi
flight 146550 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146550/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
Domain creation failure paths don't call domain_relinquish_resources(),
yet allocations and alike done from hvm_domain_initialize() need to be
undone nevertheless. Call the function also from hvm_domain_destroy(),
after making sure all descendants are idempotent.
Note that while viridian_{domain,v
XOR-ing two arbitrary non-equal values may produce 1 even if both values
are different from both 0 and 1 (2 and 3 would fit, for example). Use OR
instead, which together with the earlier bailing upon finding
"version == old_version" achieves the intended effect.
Fixes: f0ad21c499f7 ("x86 hvm: Intr
flight 146548 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146548/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
On 28.01.20 13:28, Paul Durrant wrote:
This patch details proposes extra migration data and xenstore protocol
extensions to support non-cooperative live migration of guests.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
On 27.01.2020 22:29, Igor Druzhinin wrote:
> @@ -223,6 +224,7 @@ static int enter_state(u32 state)
>
> acpi_sleep_prepare(state);
>
> +watchdog_disable();
> console_start_sync();
> printk("Entering ACPI S%d state.\n", state);
>
> @@ -281,6 +283,7 @@ static int enter_state(u
Thanks for writing this up. I skimmed through it. It looks sensible.
On Tue, Jan 28, 2020 at 12:28:22PM +, Paul Durrant wrote:
> It has become apparent to some large cloud providers that the current
> model of cooperative migration of guests under Xen is not usable as it
> relies on software r
On Tue, Jan 28, 2020 at 12:28:23PM +, Paul Durrant wrote:
> +```
> +0 1 2 3 4 5 6 7 octet
> ++++
> +| type | record specific data |
> +++|
> +...
> ++-
> -Original Message-
> From: Jürgen Groß
> Sent: 28 January 2020 13:36
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ; Konrad Rzeszutek Wilk
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
>
> Subject: Re: [Xen-devel] [PATCH v3
From: Wei Liu
We are going to switch to using domheap page for page tables.
A new set of APIs is introduced to allocate and free pages of page
tables based on mfn instead of the xenheap direct map address. The
allocation and deallocation work on mfn_t but not page_info, because
they are required
On Tue, Jan 28, 2020 at 12:52:16PM +, Andrew Cooper wrote:
> boot_cpu_has(X86_FEATURE_X2APIC) doesn't need checking to interpret
> APIC_BASE_EXTD.
>
> Also take the opportunity to optimise the generated assembly by not using
> rdmsrl(). GCC isn't clever enough to spot that it can drop the shi
On Tue, Jan 28, 2020 at 02:17:51PM +0100, Jan Beulich wrote:
> XOR-ing two arbitrary non-equal values may produce 1 even if both values
> are different from both 0 and 1 (2 and 3 would fit, for example). Use OR
> instead, which together with the earlier bailing upon finding
> "version == old_versio
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 January 2020 13:17
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant
> ; Wei Liu ; Roger Pau Monné
>
> Subject: [Xen-devel] [PATCH] x86/HVM: relinquish resources also from
> hvm_domain_destr
> -Original Message-
> From: Xen-devel On Behalf Of Wei
> Liu
> Sent: 28 January 2020 13:46
> To: Durrant, Paul
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ; Konrad Rzeszutek Wilk
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; xen-devel@lists.xenproject.org
> Subject: Re: [
On 27.01.2020 21:21, 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 identify_cpu(), and
> ends
On 28.01.2020 13:52, Andrew Cooper wrote:
> boot_cpu_has(X86_FEATURE_X2APIC) doesn't need checking to interpret
> APIC_BASE_EXTD.
Hmm, the comment you remove ...
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -1534,18 +1534,14 @@ void __init record_boot_APIC_mode(void)
> /* Look at
On Mon, Jan 27, 2020 at 07:11:15PM +0100, Roger Pau Monne wrote:
[...]
>
> const struct hypervisor_ops *__init xg_probe(void)
> diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
> index 65eb7cbda8..9bc925616a 100644
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -15,6 +15,7 @@
>
On Mon, Jan 27, 2020 at 07:11:09PM +0100, Roger Pau Monne wrote:
> The returned type wants to be bool instead of int.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lis
On Tue, Jan 28, 2020 at 01:50:05PM +, Hongyan Xia wrote:
> From: Wei Liu
>
> We are going to switch to using domheap page for page tables.
> A new set of APIs is introduced to allocate and free pages of page
> tables based on mfn instead of the xenheap direct map address. The
> allocation and
On Tue, Jan 28, 2020 at 07:21:07AM +0100, Juergen Gross wrote:
> The CONTROL command (former DEBUG command) isn't specified in the
> xenstore protocol doc. Add it.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
Backport: 4.9+
___
Xen-devel mailin
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
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
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.
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
---
tools/xenstore/xenstored_control.c | 18 ++
1 file changed, 18 insertions(+)
On 28.01.2020 15:14, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 28 January 2020 13:17
>>
>> --- a/xen/arch/x86/hvm/hpet.c
>> +++ b/xen/arch/x86/hvm/hpet.c
>> @@ -751,7 +751,7 @@ void hpet_deinit(struct domain *d)
>> int i;
>>
On 28/01/2020 13:39, Jan Beulich wrote:
> On 27.01.2020 22:29, Igor Druzhinin wrote:
>> @@ -223,6 +224,7 @@ static int enter_state(u32 state)
>>
>> acpi_sleep_prepare(state);
>>
>> +watchdog_disable();
>> console_start_sync();
>> printk("Entering ACPI S%d state.\n", state);
>
... and enable it after exiting S-state. Otherwise accumulated
output in serial buffer might easily trigger the watchdog if it's
still enabled after entering sync transmission mode.
The issue observed on machines which, unfortunately, generate non-0
output in CPU offline callbacks.
Signed-off-by:
On 28.01.2020 15:37, Igor Druzhinin wrote:
> ... and enable it after exiting S-state. Otherwise accumulated
> output in serial buffer might easily trigger the watchdog if it's
> still enabled after entering sync transmission mode.
>
> The issue observed on machines which, unfortunately, generate n
On Tue, Jan 28, 2020 at 02:16:53PM +0100, Jan Beulich wrote:
> Domain creation failure paths don't call domain_relinquish_resources(),
> yet allocations and alike done from hvm_domain_initialize() need to be
> undone nevertheless. Call the function also from hvm_domain_destroy(),
> after making sur
On Wed, Jan 22, 2020 at 08:53:45AM +, David Woodhouse wrote:
> From: David Woodhouse
>
> For live update to work, it will need a region of memory that can be
> given to the boot allocator while it parses the state information from
> the previous Xen and works out which of the other pages of m
On Tue, Jan 28, 2020 at 02:17:36PM +, Wei Liu wrote:
> On Mon, Jan 27, 2020 at 07:11:15PM +0100, Roger Pau Monne wrote:
> [...]
> >
> > const struct hypervisor_ops *__init xg_probe(void)
> > diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
> > index 65eb7cbda8..9bc925616a 100644
> > ---
> -Original Message-
> From: Jan Beulich
> Sent: 28 January 2020 14:31
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Paul Durrant ; Wei Liu
> ; Roger Pau Monné
> Subject: Re: [PATCH] x86/HVM: relinquish resources also from
> hvm_domain_destroy()
>
> On 28.0
On Wed, Jan 22, 2020 at 08:56:55PM +, Andrew Cooper wrote:
> On 22/01/2020 20:23, Wei Liu wrote:
> > diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
> > index 1cbf5acdfb..605d01f1dd 100644
> > --- a/xen/arch/x86/boot/x86_64.S
> > +++ b/xen/arch/x86/boot/x86_64.S
> > @@ -85,
> +if ( !(rc = hvm_copy_context_and_params(d, cd)) )
I just realized that I forgot to swap the order of the parameters here
after the requested change was made in the prereq patch introducing
the function.
Tamas
___
Xen-devel mailing list
Xen-devel
On Mon, Jan 27, 2020 at 07:42:27PM +0100, Thomas Zimmermann wrote:
> Hi Emil
>
> Am 27.01.20 um 19:12 schrieb Emil Velikov:
> > Hi Thomas,
> >
> > On Thu, 23 Jan 2020 at 09:21, Thomas Zimmermann wrote:
> >
> >> @@ -174,12 +174,22 @@ struct drm_crtc_state {
> >> * @no_vblank:
> >>
On Thu, Jan 23, 2020 at 12:04:00PM +0100, Jan Beulich wrote:
> On 22.01.2020 21:23, Wei Liu wrote:
> > This allows us to set aside some address space for executable mapping.
> > This fixed map range starts from XEN_VIRT_END so that it is within reach
> > of the .text section.
> >
> > Shift the per
On Wed, Jan 22, 2020 at 09:31:52PM +, Andrew Cooper wrote:
> On 22/01/2020 20:23, Wei Liu wrote:
> > Use the top-most addressable page for that purpose. Adjust e820 code
> > accordingly.
> >
> > We also need to register Xen's guest OS ID to Hyper-V. Use 0x300 as the
> > OS type.
> >
> > Signed-
On Thu, Jan 23, 2020 at 01:35:22AM +, Michael Kelley wrote:
[...]
> > diff --git a/xen/include/asm-x86/guest/hyperv-tlfs.h b/xen/include/asm-
> > x86/guest/hyperv-tlfs.h
> > index 05c4044976..5d37efd2d2 100644
> > --- a/xen/include/asm-x86/guest/hyperv-tlfs.h
> > +++ b/xen/include/asm-x86/guest
On 24.01.2020 16:31, Paul Durrant wrote:
> Currently it is unsafe to assign a domheap page allocated with
> MEMF_no_refcount to a domain because the domain't 'tot_pages' will not
> be incremented, but will be decrement when the page is freed (since
> free_domheap_pages() has no way of telling that
On 24.01.2020 16:31, Paul Durrant wrote:
> vmx_alloc_vlapic_mapping() currently contains some very odd looking code
> that allocates a MEMF_no_owner domheap page and then shares with the guest
> as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
> to call a special function
On Thu, Jan 23, 2020 at 12:18:41PM +0100, Jan Beulich wrote:
> On 22.01.2020 21:23, Wei Liu wrote:
> > --- a/xen/arch/x86/e820.c
> > +++ b/xen/arch/x86/e820.c
> > @@ -36,6 +36,22 @@ boolean_param("e820-verbose", e820_verbose);
> > struct e820map e820;
> > struct e820map __initdata e820_raw;
> >
On 28.01.2020 16:15, Wei Liu wrote:
> On Thu, Jan 23, 2020 at 12:04:00PM +0100, Jan Beulich wrote:
>> On 22.01.2020 21:23, Wei Liu wrote:
>>> This allows us to set aside some address space for executable mapping.
>>> This fixed map range starts from XEN_VIRT_END so that it is within reach
>>> of th
On 28.01.2020 16:30, Wei Liu wrote:
> On Thu, Jan 23, 2020 at 12:18:41PM +0100, Jan Beulich wrote:
>> On 22.01.2020 21:23, Wei Liu wrote:
>>> --- a/xen/arch/x86/e820.c
>>> +++ b/xen/arch/x86/e820.c
>>> @@ -36,6 +36,22 @@ boolean_param("e820-verbose", e820_verbose);
>>> struct e820map e820;
>>> st
The array is named msr_policy.
Fixes commit 60529dfeca1
Signed-off-by: Olaf Hering
---
xen/include/public/domctl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index e313da499f..2bb7397923 100644
--- a/xen/include/
> -Original Message-
> From: Wei Liu
> Sent: 28 January 2020 13:41
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ;
> Ian Jackson ; Jan Beulich ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Wei
> Liu
> Subject: Re: [PATCH v3
On 28.01.2020 15:54, Roger Pau Monné wrote:
> On Tue, Jan 28, 2020 at 02:16:53PM +0100, Jan Beulich wrote:
>> Domain creation failure paths don't call domain_relinquish_resources(),
>> yet allocations and alike done from hvm_domain_initialize() need to be
>> undone nevertheless. Call the function a
On Thu, Jan 23, 2020 at 04:45:38PM +0100, Jan Beulich wrote:
> On 22.01.2020 21:23, Wei Liu wrote:
> > --- a/xen/arch/x86/guest/hyperv/hyperv.c
> > +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> > @@ -27,7 +27,10 @@
> > #include
> > #include
> >
> > +#include "private.h"
> > +
> > struct ms_hype
On Thu, Jan 23, 2020 at 04:48:38PM +0100, Jan Beulich wrote:
> On 22.01.2020 21:23, Wei Liu wrote:
> > This will be useful when invoking hypercall that targets specific
> > vcpu(s).
> >
> > Signed-off-by: Wei Liu
> > Reviewed-by: Paul Durrant
>
> For formal reasons
> Acked-by: Jan Beulich
>
>
flight 146551 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146551/
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
flight 146553 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146553/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On 28.01.2020 16:50, Wei Liu wrote:
> On Thu, Jan 23, 2020 at 04:45:38PM +0100, Jan Beulich wrote:
>> On 22.01.2020 21:23, Wei Liu wrote:
>>> --- a/xen/arch/x86/guest/hyperv/hyperv.c
>>> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
>>> @@ -27,7 +27,10 @@
>>> #include
>>> #include
>>>
>>> +#includ
On 28.01.2020 16:55, Wei Liu wrote:
> On Thu, Jan 23, 2020 at 04:48:38PM +0100, Jan Beulich wrote:
>> On 22.01.2020 21:23, Wei Liu wrote:
>>> This will be useful when invoking hypercall that targets specific
>>> vcpu(s).
>>>
>>> Signed-off-by: Wei Liu
>>> Reviewed-by: Paul Durrant
>>
>> For forma
On Tue, Jan 28, 2020 at 03:57:04PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 28, 2020 at 02:17:36PM +, Wei Liu wrote:
> > On Mon, Jan 27, 2020 at 07:11:15PM +0100, Roger Pau Monne wrote:
> > [...]
> > >
> > > const struct hypervisor_ops *__init xg_probe(void)
> > > diff --git a/xen/arch/x8
Commit d3eeb1d77c5d ("xen/gntdev: use mmu_interval_notifier_insert")
missed a test for use_ptemod when calling mmu_interval_read_begin(). Fix
that.
Fixes: d3eeb1d77c5d ("xen/gntdev: use mmu_interval_notifier_insert")
CC: sta...@vger.kernel.org # 5.5
Reported-by: Ilpo Järvinen
Tested-by: Ilpo Järv
On 28.01.20 17:24, Boris Ostrovsky wrote:
Commit d3eeb1d77c5d ("xen/gntdev: use mmu_interval_notifier_insert")
missed a test for use_ptemod when calling mmu_interval_read_begin(). Fix
that.
Fixes: d3eeb1d77c5d ("xen/gntdev: use mmu_interval_notifier_insert")
CC: sta...@vger.kernel.org # 5.5
Repo
On Tue, Jan 28, 2020 at 11:24:19AM -0500, Boris Ostrovsky wrote:
> Commit d3eeb1d77c5d ("xen/gntdev: use mmu_interval_notifier_insert")
> missed a test for use_ptemod when calling mmu_interval_read_begin(). Fix
> that.
>
> Fixes: d3eeb1d77c5d ("xen/gntdev: use mmu_interval_notifier_insert")
> CC:
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 January 2020 16:19
> To: Wei Liu ; Paul Durrant ; Andrew Cooper
>
> Cc: Xen Development List ; Roger Pau Monné
> ; Wei Liu ; Michael Kelley
>
> Subject: Re: [Xen-devel] [PATCH v4 6/7] x86/hyperv: retrieve vp_ind
On 27.01.2020 19:06, Tamas K Lengyel wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -574,11 +574,12 @@ struct page_info *p2m_get_page_from_gfn(
> if ( fdom == NULL )
> page = NULL;
> }
> -else if ( !get_page(pag
On Tue, Jan 28, 2020 at 9:38 AM Jan Beulich wrote:
>
> On 27.01.2020 19:06, Tamas K Lengyel wrote:
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -574,11 +574,12 @@ struct page_info *p2m_get_page_from_gfn(
> > if ( fdom == NULL )
> > pa
On 27.01.2020 19:06, Tamas K Lengyel wrote:
> @@ -4139,49 +4140,32 @@ static int hvm_allow_set_param(struct domain *d,
> return rc;
> }
>
> -static int hvmop_set_param(
> -XEN_GUEST_HANDLE_PARAM(xen_hvm_param_t) arg)
> +static int hvm_set_param(struct domain *d, uint32_t index, uint64_t
On 27.01.2020 19:06, Tamas K Lengyel wrote:
> Using XENLOG_ERR level since this is only used in debug paths (ie. it's
> expected the user already has loglvl=all set). Also use %pd to print the
> domain
> ids.
>
> Signed-off-by: Tamas K Lengyel
Acked-by: Jan Beulich
__
On Tue, Jan 28, 2020 at 05:15:39PM +0100, Jan Beulich wrote:
> On 28.01.2020 16:50, Wei Liu wrote:
> > On Thu, Jan 23, 2020 at 04:45:38PM +0100, Jan Beulich wrote:
> >> On 22.01.2020 21:23, Wei Liu wrote:
> >>> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> >>> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
On Tue, Jan 28, 2020 at 04:33:00PM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Xen-devel On Behalf Of Jan
> > Beulich
> > Sent: 28 January 2020 16:19
> > To: Wei Liu ; Paul Durrant ; Andrew Cooper
> >
> > Cc: Xen Development List ; Roger Pau Monné
> > ; Wei Liu ; Michael
On Tue, Jan 28, 2020 at 9:48 AM Jan Beulich wrote:
>
> On 27.01.2020 19:06, Tamas K Lengyel wrote:
> > @@ -4139,49 +4140,32 @@ static int hvm_allow_set_param(struct domain *d,
> > return rc;
> > }
> >
> > -static int hvmop_set_param(
> > -XEN_GUEST_HANDLE_PARAM(xen_hvm_param_t) arg)
> >
On 27.01.2020 19:06, Tamas K Lengyel wrote:
> When plugging a hole in the target physmap don't use the access permission
> returned by __get_gfn_type_access as it can be non-sensical, leading to
> spurious vm_events being sent out for access violations at unexpected
> locations. Make use of p2m->de
On Tue, Jan 28, 2020 at 04:46:14PM +0100, Olaf Hering wrote:
> The array is named msr_policy.
>
> Fixes commit 60529dfeca1
>
> Signed-off-by: Olaf Hering
Acked-by: Wei Liu
Backport: 4.12+
> ---
> xen/include/public/domctl.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --
On 28.01.2020 17:54, Tamas K Lengyel wrote:
> On Tue, Jan 28, 2020 at 9:48 AM Jan Beulich wrote:
>>
>> On 27.01.2020 19:06, Tamas K Lengyel wrote:
>>> @@ -4139,49 +4140,32 @@ static int hvm_allow_set_param(struct domain *d,
>>> return rc;
>>> }
>>>
>>> -static int hvmop_set_param(
>>> -X
On 28.01.2020 17:59, Wei Liu wrote:
> On Tue, Jan 28, 2020 at 04:46:14PM +0100, Olaf Hering wrote:
>> The array is named msr_policy.
>>
>> Fixes commit 60529dfeca1
>>
>> Signed-off-by: Olaf Hering
>
> Acked-by: Wei Liu
> Backport: 4.12+
Why? This kind of a change hardly warrants a backport imo.
> -Original Message-
> From: Jan Beulich
> Sent: 28 January 2020 15:23
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ;
> Ian Jackson ; Julien Grall ;
> Konrad Rzeszutek Wilk ; Stefano Stabellini
> ; Wei Liu ; Volodymyr Babchuk
> ; Roger Pau Monn
> -Original Message-
> From: Wei Liu
> Sent: 28 January 2020 16:54
> To: Durrant, Paul
> Cc: Jan Beulich ; Wei Liu ; Paul Durrant
> ; Andrew Cooper ; Xen Development
> List ; Roger Pau Monné
> ; Wei Liu ; Michael Kelley
>
> Subject: Re: [Xen-devel] [PATCH v4 6/7] x86/hyperv: retrieve vp_
On Tue, Jan 28, 2020 at 06:00:45PM +0100, Jan Beulich wrote:
> On 28.01.2020 17:59, Wei Liu wrote:
> > On Tue, Jan 28, 2020 at 04:46:14PM +0100, Olaf Hering wrote:
> >> The array is named msr_policy.
> >>
> >> Fixes commit 60529dfeca1
> >>
> >> Signed-off-by: Olaf Hering
> >
> > Acked-by: Wei Liu
On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich wrote:
>
> On 27.01.2020 19:06, Tamas K Lengyel wrote:
> > When plugging a hole in the target physmap don't use the access permission
> > returned by __get_gfn_type_access as it can be non-sensical, leading to
> > spurious vm_events being sent out for ac
On Tue, Jan 28, 2020 at 9:59 AM Jan Beulich wrote:
>
> On 28.01.2020 17:54, Tamas K Lengyel wrote:
> > On Tue, Jan 28, 2020 at 9:48 AM Jan Beulich wrote:
> >>
> >> On 27.01.2020 19:06, Tamas K Lengyel wrote:
> >>> @@ -4139,49 +4140,32 @@ static int hvm_allow_set_param(struct domain *d,
> >>>
1 - 100 of 122 matches
Mail list logo
