On 04.11.2019 23:44, Thomas Gleixner wrote:
> On Tue, 29 Oct 2019, Jan Beulich wrote:
>
>> Once again RPL checks have been introduced which don't account for a
>> 32-bit kernel living in ring 1 when running in a PV Xen domain.
>>
>> The case in FIXUP_FRAME has been preventing boot; adjust BUG_IF_W
Committers,
Please don't push any new patch to staging because we want to have a
push to master for 4.13-RC2.
Another email will be sent once the moratorium is lifted.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.x
On Thu, Oct 24, 2019 at 5:11 AM David Hildenbrand wrote:
>
> Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
> change that.
>
> KVM has this weird use case that you can map anything from /dev/mem
> into the guest. pfn_valid() is not a reliable check whether the memmap
> was ini
On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote:
> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
> > @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct
> > *vma)
> > struct gntdev_priv *priv = file->private_data;
> >
> > pr_debug("gntdev_vma_close %p\n"
On Thu, Oct 24, 2019 at 5:10 AM David Hildenbrand wrote:
>
> Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
> change that.
>
> KVM has this weird use case that you can map anything from /dev/mem
> into the guest. pfn_valid() is not a reliable check whether the memmap
> was ini
flight 143589 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143589/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 143023
test-amd64-i386-libvirt
On Thu, Oct 24, 2019 at 5:10 AM David Hildenbrand wrote:
>
> Our onlining/offlining code is unnecessarily complicated. Only memory
> blocks added during boot can have holes (a range that is not
> IORESOURCE_SYSTEM_RAM). Hotplugged memory never has holes (e.g., see
> add_memory_resource()). All boo
On 05/11/2019 00:25, Andrew Cooper wrote:
> On 04/11/2019 23:42, Andrew Cooper wrote:
>> On 04/11/2019 23:20, Håkon Alstadheim wrote:
>>> (XEN) RFLAGS=0x0193 (0x0193) DR7 = 0x0400
>>>
>>> (XEN) *** Insn bytes from b8868f61d69a: 44 00 00 8c d0 9c 81 0c 24
>>> 00 01 00 00 9d
On 04/11/2019 23:42, Andrew Cooper wrote:
> On 04/11/2019 23:20, Håkon Alstadheim wrote:
>> (XEN) RFLAGS=0x0193 (0x0193) DR7 = 0x0400
>>
>> (XEN) *** Insn bytes from b8868f61d69a: 44 00 00 8c d0 9c 81 0c 24
>> 00 01 00 00 9d 8e d0 9c 81 24 24 ff fe ff ff 9d c3 cc cc cc
>>
On 04/11/2019 23:20, Håkon Alstadheim wrote:
>
> (XEN) RFLAGS=0x0193 (0x0193) DR7 = 0x0400
>
> (XEN) *** Insn bytes from b8868f61d69a: 44 00 00 8c d0 9c 81 0c 24
> 00 01 00 00 9d 8e d0 9c 81 24 24 ff fe ff ff 9d c3 cc cc cc
> cc cc
Ok. One question answered, several mor
flight 143586 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143586/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 143158
test-amd64-amd
On Tue, 29 Oct 2019, Jan Beulich wrote:
> Once again RPL checks have been introduced which don't account for a
> 32-bit kernel living in ring 1 when running in a PV Xen domain.
>
> The case in FIXUP_FRAME has been preventing boot; adjust BUG_IF_WRONG_CR3
> as well just in case.
Either it's requir
On 10/24/19 8:09 AM, David Hildenbrand wrote:
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 4f2e78a5e4db..af69f057913a 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -374,6 +374,13 @@ static void xen_online_page(struct page *page, unsigned
> int orde
On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
> @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma)
> struct gntdev_priv *priv = file->private_data;
>
> pr_debug("gntdev_vma_close %p\n", vma);
> - if (use_ptemod) {
> - /* It is possible that an
On Fri, Nov 01, 2019 at 01:54:45PM -0700, Ralph Campbell wrote:
> You can add my Tested-by for the mm and nouveau changes.
> IOW, patches 1-4, 10-11, and 15.
>
> Tested-by: Ralph Campbell
Got it, thanks
Jason
___
Xen-devel mailing list
Xen-devel@list
On 04/11/2019 15:40, Andrew Cooper wrote:
> On 04/11/2019 15:33, Håkon Alstadheim wrote:
>> Den 04.11.2019 14:31, skrev Andrew Cooper:
>>> On 03/11/2019 10:23, Håkon Alstadheim wrote:
>>>
(XEN) [2019-11-02 14:09:46] d2v0 vmentry failure (reason 0x8021):
Invalid guest state (0)
(X
flight 143566 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143566/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 142915
test-amd64-amd64-
In e9b0653875b3 we changed one of the `1000' values to `5000'. But
this magic number had been duplicated. Urgh!
The result is that adhoc-revtuple-generator might generate a weirdly
truncated output which causes cs-bisection-stop to fail with messages
like this:
*** not RelvUp at 3d40147282670d
On 31.10.2019 20:28, Andrew Cooper wrote:
> This code is especially tangled. VCPUOP_initialise calls into
> arch_initialise_vcpu() which calls back into default_initialise_vcpu() which
> is common code.
>
> This path is actually dead code on ARM, because VCPUOP_initialise is filtered
> out by do_
On 04.11.19 16:19, Jan Beulich wrote:
On 04.11.2019 16:09, Jürgen Groß wrote:
On 04.11.19 15:35, Jan Beulich wrote:
On 04.11.2019 14:58, Juergen Gross wrote:
__xen_evtchn_do_upcall() contains guards against being called
recursively. This mechanism was introduced in the early pvops times
(kerne
On 04.11.2019 16:31, Andrew Cooper wrote:
> On 04/11/2019 13:32, Jan Beulich wrote:
>> On 01.11.2019 21:25, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/boot/head.S
>>> +++ b/xen/arch/x86/boot/head.S
>>> @@ -630,6 +630,10 @@ trampoline_setup:
>>>
>>> 1:
>>> /* Interrogate CPU extended fe
On 04/11/2019 15:33, Håkon Alstadheim wrote:
>
> Den 04.11.2019 14:31, skrev Andrew Cooper:
>> On 03/11/2019 10:23, Håkon Alstadheim wrote:
>>
>>> (XEN) [2019-11-02 14:09:46] d2v0 vmentry failure (reason 0x8021):
>>> Invalid guest state (0)
>>> (XEN) [2019-11-02 14:09:46] * VMCS Are
Den 04.11.2019 14:31, skrev Andrew Cooper:
On 03/11/2019 10:23, Håkon Alstadheim wrote:
(XEN) [2019-11-02 14:09:46] d2v0 vmentry failure (reason 0x8021):
Invalid guest state (0)
(XEN) [2019-11-02 14:09:46] * VMCS Area **
(XEN) [2019-11-02 14:09:46] *** Guest State *
On 04.11.2019 16:22, Andrew Cooper wrote:
> On 04/11/2019 15:03, Jan Beulich wrote:
>> On 04.11.2019 15:59, Andrew Cooper wrote:
>>> On 04/11/2019 13:25, Jan Beulich wrote:
On 01.11.2019 21:25, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
>
Before 93dcc22, error from setting the vnc password to an empty
string, when QEMU wasn't expected a password, never prevented the creation
of a guest, and only logged an error message.
Reported-by: Roger Pau Monné
Fixes: 93dcc22fe798c9fa5ce117f1ed6db0d8bd779020
Signed-off-by: Anthony PERARD
---
On 04/11/2019 13:32, Jan Beulich wrote:
> On 01.11.2019 21:25, Andrew Cooper wrote:
>> --- a/xen/arch/x86/boot/head.S
>> +++ b/xen/arch/x86/boot/head.S
>> @@ -630,6 +630,10 @@ trampoline_setup:
>>
>> 1:
>> /* Interrogate CPU extended features via CPUID. */
>> +mov $1, %eax
>
On 04/11/2019 15:03, Jan Beulich wrote:
> On 04.11.2019 15:59, Andrew Cooper wrote:
>> On 04/11/2019 13:25, Jan Beulich wrote:
>>> On 01.11.2019 21:25, Andrew Cooper wrote:
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -270,6 +270,7 @@ static void early_init_intel(
On 04.11.2019 16:09, Jürgen Groß wrote:
> On 04.11.19 15:35, Jan Beulich wrote:
>> On 04.11.2019 14:58, Juergen Gross wrote:
>>> __xen_evtchn_do_upcall() contains guards against being called
>>> recursively. This mechanism was introduced in the early pvops times
>>> (kernel 2.6.26) when there were
On Fri, Nov 01, 2019 at 01:55:57PM -0700, H. Peter Anvin wrote:
> On 2019-10-24 04:48, Daniel Kiper wrote:
> > This field contains maximal allowed type for setup_data.
> >
> > Now bump the setup_header version in arch/x86/boot/header.S.
>
> Please don't bump the protocol revision here, otherwise we
Hi,
Due to very limited space in the setup_header this patch series introduces new
kernel_info struct which will be used to convey information from the kernel to
the bootloader. This way the boot protocol can be extended regardless of the
setup_header limitations. Additionally, the patch series in
This field contains maximal allowed type for setup_data.
This patch does not bump setup_header version in arch/x86/boot/header.S
because it will be followed by additional changes coming into the
Linux/x86 boot protocol.
Suggested-by: H. Peter Anvin (Intel)
Signed-off-by: Daniel Kiper
Reviewed-b
The relationships between the headers are analogous to the various data
sections:
setup_header = .data
boot_params/setup_data = .bss
What is missing from the above list? That's right:
kernel_info = .rodata
We have been (ab)using .data for things that could go into .rodata or .bss for
a lo
The setup_data is a bit awkward to use for extremely large data objects,
both because the setup_data header has to be adjacent to the data object
and because it has a 32-bit length field. However, it is important that
intermediate stages of the boot process have a way to identify which
chunks of me
On 04.11.19 15:35, Jan Beulich wrote:
On 04.11.2019 14:58, Juergen Gross wrote:
__xen_evtchn_do_upcall() contains guards against being called
recursively. This mechanism was introduced in the early pvops times
(kernel 2.6.26) when there were still Xen versions around not honoring
disabled interr
On 04.11.2019 15:59, Andrew Cooper wrote:
> On 04/11/2019 13:25, Jan Beulich wrote:
>> On 01.11.2019 21:25, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/intel.c
>>> +++ b/xen/arch/x86/cpu/intel.c
>>> @@ -270,6 +270,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)
>>> if (disable) {
>
On 04/11/2019 13:25, Jan Beulich wrote:
> On 01.11.2019 21:25, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu/intel.c
>> +++ b/xen/arch/x86/cpu/intel.c
>> @@ -270,6 +270,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)
>> if (disable) {
>> wrmsrl(MSR_IA32_MISC_ENABLE, misc
On Mon, Oct 28, 2019 at 4:06 PM Oleksandr Grytsov wrote:
>
> On Wed, Oct 16, 2019 at 4:26 PM Oleksandr Grytsov wrote:
> >
> > On Fri, Oct 11, 2019 at 8:04 PM Ian Jackson wrote:
> > >
> > > Oleksandr Grytsov writes ("Re: [PATCH v1 1/2] libxl: introduce new
> > > backend type VINPUT"):
> > > > On
On 04.11.2019 14:58, Juergen Gross wrote:
> __xen_evtchn_do_upcall() contains guards against being called
> recursively. This mechanism was introduced in the early pvops times
> (kernel 2.6.26) when there were still Xen versions around not honoring
> disabled interrupts for sending events to pv gue
__xen_evtchn_do_upcall() contains guards against being called
recursively. This mechanism was introduced in the early pvops times
(kernel 2.6.26) when there were still Xen versions around not honoring
disabled interrupts for sending events to pv guests.
This was changed in Xen 3.0, which is much o
On 01.11.2019 21:25, Andrew Cooper wrote:
> From: Sergey Dyasli
>
> Converting a guest from PV to PV-in-PVH makes the guest to have 384k
> less memory, which may confuse guest's balloon driver. This happens
> because Xen unconditionally reserves 640k - 1M region in E820 despite
> the fact that it
On 01.11.2019 21:25, Andrew Cooper wrote:
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -630,6 +630,10 @@ trampoline_setup:
>
> 1:
> /* Interrogate CPU extended features via CPUID. */
> +mov $1, %eax
> +cpuid
> +mov %ecx, sym_fs(b
On 03/11/2019 10:23, Håkon Alstadheim wrote:
> (XEN) [2019-11-02 14:09:46] d2v0 vmentry failure (reason 0x8021):
> Invalid guest state (0)
> (XEN) [2019-11-02 14:09:46] * VMCS Area **
> (XEN) [2019-11-02 14:09:46] *** Guest State ***
> (XEN) [2019-11-02 14:09:46] CR0: a
On 01.11.2019 21:25, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -270,6 +270,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)
> if (disable) {
> wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable & ~disable);
> bootsym(
On 01.11.2019 19:49, Andrew Cooper wrote:
> On 01/11/2019 14:29, Andrew Cooper wrote:
>> On 01/11/2019 14:00, Eslam Elnikety wrote:
>>> Thanks for this series, Jan.
>>>
>>> On 30.10.19 11:39, Jan Beulich wrote:
To fulfill the "protected" in its name, don't let the real hardware
values "sh
> -Original Message-
> From: Anthony PERARD
> Sent: 04 November 2019 12:14
> To: Durrant, Paul
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org; jgr...@suse.com; Igor Druzhinin
> ; jbeul...@suse.com
> Subject: Re: [Xen-devel] [PATCH for-4.13 v2] passthrough: simplify locking
> and
On Mon, Nov 04, 2019 at 11:13:48AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Andrew Cooper
> > Sent: 04 November 2019 11:06
> > To: Durrant, Paul ; xen-devel@lists.xenproject.org
> > Cc: Igor Druzhinin ; jgr...@suse.com;
> > jbeul...@suse.com
> > Subject: Re: [Xen-devel]
flight 143563 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143563/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow18 guest-localmigrate/x10 fail REGR. vs. 142750
test-amd64-amd64-x
osstest service owner writes ("[osstest test] 143493: regressions - FAIL"):
> flight 143493 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/143493/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-
Dear community members,
please send me agenda items for next week’s community call. A draft agenda is
at https://cryptpad.fr/pad/#/2/pad/edit/SkeU+Z5J9WIIU9ZsXlojiXcQ/
Please add agenda items to the document or reply to this e-mail
Note that I am on PTO today and tomorrow
Last month’s minutes
> -Original Message-
> From: Andrew Cooper
> Sent: 04 November 2019 11:06
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Igor Druzhinin ; jgr...@suse.com;
> jbeul...@suse.com
> Subject: Re: [Xen-devel] [PATCH for-4.13 v2] passthrough: simplify locking
> and logging
>
> On 04/1
On 04/11/2019 08:31, Durrant, Paul wrote:
>> -Original Message-
>> From: Igor Druzhinin
>> Sent: 01 November 2019 19:28
>> To: xen-devel@lists.xenproject.org
>> Cc: Durrant, Paul ; jbeul...@suse.com;
>> jgr...@suse.com
>> Subject: [PATCH for-4.13 v2] passthrough: simplify locking and loggi
On 01.11.2019 19:35, Andrew Cooper wrote:
> On 30/10/2019 12:02, Jan Beulich wrote:
>> On 30.10.2019 12:43, Andrew Cooper wrote:
>>> On 30/10/2019 10:39, Jan Beulich wrote:
To fulfill the "protected" in its name, don't let the real hardware
values "shine through". Report a control registe
On Sat, Nov 02, 2019 at 07:48:06AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné [mailto:roger@citrix.com]
> > Sent: Thursday, October 31, 2019 11:23 PM
> >
> > On Thu, Oct 31, 2019 at 07:52:23AM -0700, Joe Jin wrote:
> > > On 10/31/19 1:01 AM, Jan Beulich wrote:
> > > > On 30.10.2019 19
> -Original Message-
> From: Igor Druzhinin
> Sent: 01 November 2019 19:28
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; jbeul...@suse.com;
> jgr...@suse.com
> Subject: [PATCH for-4.13 v2] passthrough: simplify locking and logging
>
> From: Paul Durrant
>
> Dropping the pci
On 01.11.2019 15:00, Eslam Elnikety wrote:
> On 30.10.19 11:39, Jan Beulich wrote:
>> @@ -237,6 +239,18 @@ int guest_rdmsr(struct vcpu *v, uint32_t
>> ARRAY_SIZE(msrs->dr_mask))];
>> break;
>>
>> +case MSR_PPIN_CTL:
>> +if ( d->arch.cpui
On 01.11.2019 15:29, Andrew Cooper wrote:
> On 01/11/2019 14:00, Eslam Elnikety wrote:
>> Thanks for this series, Jan.
>>
>> On 30.10.19 11:39, Jan Beulich wrote:
>>> To fulfill the "protected" in its name, don't let the real hardware
>>> values "shine through". Report a control register value expr
56 matches
Mail list logo
