On 28.01.20 18:41, PGNet Dev wrote:
( posted this already to xen-users, and @ distro list; advised to bring it here
)
I'm running linux kernel
lsb_release -rd
Description:openSUSE Leap 15.1
Release:15.1
uname -rm
flight 146559 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146559/
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
flight 146561 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146561/
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
flight 146560 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146560/
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
flight 146555 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146555/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
146543
Tests
Xen Community meeting at Citrix, December 2019
==
*Combined Notes from Christopher Clark and Daniel P. Smith*
# Day One @ Xen meeting
## Attendees
- Daniel Smith (Apertus Solutions/TrenchBoot/OpenXT)
- Christopher Clark (OpenXT)
- Rich Persaud
flight 146558 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146558/
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
flight 146557 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146557/
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
> I think marshaling and unmarshalling should be fine, *as long as* the
> structure being unmarshalled actually went through the
> libxl__init() function first.
>
> In fact, I was kicking around the idea of adding a non-exported field to
> all the generated structs -- maybe "bool initalized" --
flight 146554 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146554/
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
flight 146552 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146552/
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
flight 146556 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146556/
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 09:32, Julien Grall wrote:
> 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
Wei Liu writes ("Re: [PATCH v2] docs: document CONTROL command of xenstore
protocol"):
> 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
>
( posted this already to xen-users, and @ distro list; advised to bring it here
)
I'm running linux kernel
lsb_release -rd
Description:openSUSE Leap 15.1
Release:15.1
uname -rm
5.4.14-25.g170524c-default x86_64
On Tue, Jan 28, 2020 at 05:20:25PM +, Andrew Cooper wrote:
> On 28/01/2020 17:16, Roger Pau Monné wrote:
> OOI why isn't tlb_clk_enabled set to false when Xen determines to use L0
> assisted flush?
> >>> L0 assisted flush can fail (ie: return an error), and in that case Xen
> >>>
On Tue, Jan 28, 2020 at 04:49:09PM +0100, Jan Beulich wrote:
> 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
On 28/01/2020 17:16, Roger Pau Monné wrote:
OOI why isn't tlb_clk_enabled set to false when Xen determines to use L0
assisted flush?
>>> L0 assisted flush can fail (ie: return an error), and in that case Xen
>>> would be better to continue using the timestamped tlb, as it could
>>> avoid
On Tue, Jan 28, 2020 at 04:24:24PM +, Wei Liu wrote:
> 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
On 28/01/2020 13:59, Jan Beulich wrote:
> 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
> -Original Message-
[snip]
> > > @@ -2331,11 +2331,20 @@ struct page_info *alloc_domheap_pages(
> > >memflags, d)) == NULL)) )
> > > return NULL;
> > >
> > > -if ( d && !(memflags & MEMF_no_owner) &&
> > > - assign_pages(d, pg,
On Tue, Jan 28, 2020 at 03:47:02PM +, Durrant, Paul wrote:
[...]
>
> > > +memory pages which are shared between the two domains, but this channel
> > of
> > > +communication is generally established using xenstore (the store
> > protocol
> > > +itself being an exception to this for obvious
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,
> >>>
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
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
> -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
> -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
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
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(
>>> -
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 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
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 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 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 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 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,
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 )
> >
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 (
> -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
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:
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
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
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
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
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
>>>
>>>
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 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
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
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
> -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
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
---
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;
>>>
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
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 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 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 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
> > +++
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.
> >
> >
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
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:
> >>
> +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
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
> > @@
> -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
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
> > ---
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
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
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
... 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.
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);
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;
>>
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(+)
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.
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,
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
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
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
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
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
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 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
> -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:
> -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
>
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 ==
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
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: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
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
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
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
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
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
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:
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
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
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
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
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
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 ;
1 - 100 of 122 matches
Mail list logo
