On 28.11.2019 10:38, Paul Durrant wrote:
> From: Julien Grall
>
> A guest will setup a shared page with the hypervisor for each vCPU via
> XENPMU_init. The page will then get mapped in the hypervisor and only
> released when XENPMU_finish is called.
>
> This means that if the guest fails to invo
On 29.11.2019 02:41, Yi Sun wrote:
> On 19-11-28 12:25:44, Jan Beulich wrote:
>> On 28.11.2019 11:18, Yi Sun wrote:
>>> --- a/xen/arch/x86/psr.c
>>> +++ b/xen/arch/x86/psr.c
>>> @@ -1271,7 +1271,8 @@ static void do_write_psr_msrs(void *data)
>>>
>>> for ( j = 0; j < cos_num; j++, index++
flight 144368 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144368/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
144304
Tests which did not
Hello,
I would like to paravirtualize several instances of a minimal Linux solution
with xen. Guest OS have a PCI passthrough access on the ethernet interfaces.
I use a pvops kernel 4.4.122 , xen 4.11.2 and an x86 platform. My hardware
platform doesn't support IOMMU but I doesn't need hard segm
flight 144359 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144359/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 85 leak-check/check fail REGR. vs. 143721
test-xtf-amd64-amd64-1
flight 144358 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144358/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 144344
test-amd64-amd64-xl-qemut-win7-amd64
During test, we found a crash on Xen with below trace.
(XEN) Xen call trace:
(XEN)[] R psr.c#l3_cdp_write_msr+0x1e/0x22
(XEN)[] F psr.c#do_write_psr_msrs+0x6d/0x109
(XEN)[] F smp_call_function_interrupt+0x5a/0xac
(XEN)[] F call_function_interrupt+0x20/0x34
(XEN)[] F do_IRQ+0x175
The switch of guest_console_write()'s second parameter from plain to
unsigned int has caused the function's main loop header to no longer
guard the min_t() use within the function against effectively negative
values, due to the casts hidden inside the macro. Replace by a plain
min(), converting one
On 29.11.2019 11:01, Yi Sun wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -1271,7 +1271,13 @@ static void do_write_psr_msrs(void *data)
>
> for ( j = 0; j < cos_num; j++, index++ )
> {
> -if ( feat->cos_reg_val[cos * cos_num + j] != info->val[inde
On 29/11/2019 10:13, Jan Beulich wrote:
> The switch of guest_console_write()'s second parameter from plain to
> unsigned int has caused the function's main loop header to no longer
> guard the min_t() use within the function against effectively negative
> values, due to the casts hidden inside the
On 28.11.2019 17:52, Paul Durrant wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -84,11 +84,40 @@ struct grant_table {
> struct grant_table_arch arch;
> };
>
> +static int parse_gnttab_limit(const char *param, const char *arg,
> +
On 29.11.2019 11:22, Andrew Cooper wrote:
> On 29/11/2019 10:13, Jan Beulich wrote:
>> The switch of guest_console_write()'s second parameter from plain to
>> unsigned int has caused the function's main loop header to no longer
>> guard the min_t() use within the function against effectively negati
On 29.11.2019 11:22, Jan Beulich wrote:
> On 28.11.2019 17:52, Paul Durrant wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -84,11 +84,40 @@ struct grant_table {
>> struct grant_table_arch arch;
>> };
>>
>> +static int parse_gnttab_limit(const char *param, c
flight 144375 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144375/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 85 leak-check/check fail REGR. vs. 143721
Tests which did not succeed
> -Original Message-
> From: Jan Beulich
> Sent: 29 November 2019 10:29
> To: Durrant, Paul
> Cc: Andrew Cooper ; Anthony PERARD
> ; George Dunlap ;
> Roger Pau Monné ; Volodymyr Babchuk
> ; George Dunlap ;
> Ian Jackson ; Marek Marczykowski-Górecki
> ; Stefano Stabellini
> ; xen-devel@li
Hi,
On 29/11/2019 10:13, Jan Beulich wrote:
The switch of guest_console_write()'s second parameter from plain to
unsigned int has caused the function's main loop header to no longer
guard the min_t() use within the function against effectively negative
values, due to the casts hidden inside the
On 29.11.2019 09:58, DOZ, MARC (ext) wrote:
> Hello,
>
> I would like to paravirtualize several instances of a minimal Linux solution
> with xen. Guest OS have a PCI passthrough access on the ethernet interfaces.
> I use a pvops kernel 4.4.122 , xen 4.11.2 and an x86 platform. My hardware
> p
On 29.11.2019 11:39, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 29 November 2019 10:29
>> To: Durrant, Paul
>> Cc: Andrew Cooper ; Anthony PERARD
>> ; George Dunlap ;
>> Roger Pau Monné ; Volodymyr Babchuk
>> ; George Dunlap ;
>> Ian Jackson ; Marek Marczykow
> -Original Message-
> From: Jan Beulich
> Sent: 29 November 2019 10:46
> To: Durrant, Paul
> Cc: Andrew Cooper ; Anthony PERARD
> ; George Dunlap ;
> Roger Pau Monné ; Volodymyr Babchuk
> ; George Dunlap ;
> Ian Jackson ; Marek Marczykowski-Górecki
> ; Stefano Stabellini
> ; xen-devel@li
flight 144378 xtf running [real]
http://logs.test-lab.xenproject.org/osstest/logs/144378/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4queued
test-xtf-amd64-amd64-2
Hello,
The following series aims to allow enabling x2APIC mode without
interrupt remapping support. The main usage of this would be in
virtualized environments, that usually provide x2APIC support but not
interrupt remapping.
See the last patch for some performance numbers of using x2APIC over
xA
x2APIC mode doesn't mandate interrupt remapping, and hence can be
enabled independently. This patch enables x2APIC when available,
regardless of whether there's interrupt remapping support.
This is beneficial specially when running on virtualized environments,
since it reduces the amount of vmexit
The IO-APIC code assumes that x2apic being enabled also implies
interrupt remapping being enabled, and hence will use the 32bit
destination field in the IO-APIC entry.
This is safe now, but there's no reason to not enable x2APIC even
without interrupt remapping, and hence the IO-APIC code needs to
Check that the processor to be woken up APIC ID is addressable in the
current APIC mode.
Note that in practice systems with APIC IDs > 255 should already have
x2APIC enabled by the firmware, and hence this is mostly a safety
belt.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/smpboot.c | 7 ++
Cluster mode can only be used with interrupt remapping support, since
the top 16bits of the APIC ID are filled with the cluster ID, and
hence on systems where the physical ID is still smaller than 255 the
cluster ID is not. Force x2APIC to use physical mode if there's no
interrupt remapping support
On 21.11.2019 16:02, Alexandru Stefan ISAILA wrote:
> Changes since V2:
> - Add a new structure "xen_hvm_altp2m_suppress_ve_multi"
> - Copy the gfn of the first error to the caller
> - Revert xen_hvm_altp2m_suppress_ve
> - Add a mechanism to save the first error.
And I gues
Add a module_exit() to perform the necessary clean-up. Also add
__module_get() and module_put() calls into xen_blkif_alloc() and
xen_blkif_free() respectively to make sure an in-use module cannot be
unloaded.
Signed-off-by: Paul Durrant
---
Cc: Konrad Rzeszutek Wilk
Cc: "Roger Pau Monné"
Cc: Je
On Fri, Nov 29, 2019 at 12:28:49PM +0100, Roger Pau Monne wrote:
> Cluster mode can only be used with interrupt remapping support, since
> the top 16bits of the APIC ID are filled with the cluster ID, and
> hence on systems where the physical ID is still smaller than 255 the
> cluster ID is not. Fo
On 21.11.2019 16:02, Alexandru Stefan ISAILA wrote:
> Changes since V2:
> - Drop static from xenmem_access_to_p2m_access() and declare it
> in mem_access.h
> - Use xenmem_access_to_p2m_access() in p2m_init_next_altp2m()
> - Pull out the p2m specifics from p2m_init_altp2m_ept().
I
On 29.11.2019 12:31, Paul Durrant wrote:
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -173,6 +173,8 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
> init_completion(&blkif->drain_complete);
> INIT_WORK(&blkif->free_work, xen_blki
Jan Beulich writes ("[PATCH] console: avoid buffer overflow in
guest_console_write()"):
> The switch of guest_console_write()'s second parameter from plain to
> unsigned int has caused the function's main loop header to no longer
> guard the min_t() use within the function against effectively nega
On 29.11.19 11:22, Jan Beulich wrote:
On 28.11.2019 17:52, Paul Durrant wrote:
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -84,11 +84,40 @@ struct grant_table {
struct grant_table_arch arch;
};
+static int parse_gnttab_limit(const char *param, const char *arg,
+
Jan Beulich writes ("Re: [PATCH] console: avoid buffer overflow in
guest_console_write()"):
> On 29.11.2019 11:22, Andrew Cooper wrote:
> > Is sizeof(array[0]) always 0, or is this just a GCC-ism ? Godbolt
> > suggests is 0 on all compiler we support.
> >
> > Either way, isn't the more common id
On 29.11.19 11:13, Jan Beulich wrote:
The switch of guest_console_write()'s second parameter from plain to
unsigned int has caused the function's main loop header to no longer
guard the min_t() use within the function against effectively negative
values, due to the casts hidden inside the macro.
On 25.11.2019 18:22, Roger Pau Monne wrote:
> When PCID is not available Xen does a full tlbflush by toggling the
> PGE bit in CR4. This is not necessary if PGE is not enabled, since a
> flush can be performed by writing to CR3 in that case.
>
> Change the code in do_tlb_flush to only toggle the P
On 29/11/2019 12:01, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] console: avoid buffer overflow in
> guest_console_write()"):
>> On 29.11.2019 11:22, Andrew Cooper wrote:
>>> Is sizeof(array[0]) always 0, or is this just a GCC-ism ? Godbolt
>>> suggests is 0 on all compiler we support.
On 25.11.2019 18:22, Roger Pau Monne wrote:
> When using global pages a full tlb flush can only be performed by
> toggling the PGE bit in CR4, which is usually quite expensive in terms
> of performance when running virtualized. This is specially relevant on
> AMD hardware, which doesn't have the ab
On 29/11/2019 12:09, Jan Beulich wrote:
> On 25.11.2019 18:22, Roger Pau Monne wrote:
>> When using global pages a full tlb flush can only be performed by
>> toggling the PGE bit in CR4, which is usually quite expensive in terms
>> of performance when running virtualized. This is specially relevant
On 29.11.2019 13:01, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] console: avoid buffer overflow in
> guest_console_write()"):
>> On 29.11.2019 11:22, Andrew Cooper wrote:
>>> Is sizeof(array[0]) always 0, or is this just a GCC-ism ? Godbolt
>>> suggests is 0 on all compiler we support.
On 29/11/2019 12:13, Jan Beulich wrote:
> On 29.11.2019 13:01, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH] console: avoid buffer overflow in
>> guest_console_write()"):
>>> On 29.11.2019 11:22, Andrew Cooper wrote:
Is sizeof(array[0]) always 0, or is this just a GCC-ism ? Godbolt
On 29.11.2019 12:59, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH] console: avoid buffer overflow in
> guest_console_write()"):
>> The switch of guest_console_write()'s second parameter from plain to
>> unsigned int has caused the function's main loop header to no longer
>> guard the min_t() u
> -Original Message-
> From: Jan Beulich
> Sent: 29 November 2019 11:56
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; linux-bl...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Roger Pau Monné ; Jens Axboe
> ; Konrad Rzeszutek Wilk
> Subject: Re: [PATCH] xen-blkback: allow
On 29/11/2019 12:15, Jan Beulich wrote:
> On 29.11.2019 12:59, Ian Jackson wrote:
>> Jan Beulich writes ("[PATCH] console: avoid buffer overflow in
>> guest_console_write()"):
>>> The switch of guest_console_write()'s second parameter from plain to
>>> unsigned int has caused the function's main l
On 29.11.2019 13:01, Jürgen Groß wrote:
> On 29.11.19 11:22, Jan Beulich wrote:
>> On 28.11.2019 17:52, Paul Durrant wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -84,11 +84,40 @@ struct grant_table {
>>> struct grant_table_arch arch;
>>> };
>>>
>>>
On 29.11.2019 13:15, Andrew Cooper wrote:
> On 29/11/2019 12:13, Jan Beulich wrote:
>> On 29.11.2019 13:01, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: [PATCH] console: avoid buffer overflow in
>>> guest_console_write()"):
On 29.11.2019 11:22, Andrew Cooper wrote:
> Is sizeof(array[0]
On 29.11.19 13:17, Jan Beulich wrote:
On 29.11.2019 13:01, Jürgen Groß wrote:
On 29.11.19 11:22, Jan Beulich wrote:
On 28.11.2019 17:52, Paul Durrant wrote:
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -84,11 +84,40 @@ struct grant_table {
struct grant_table_arch arc
>Except that this is not a "fix", but the introduction of a security
>vulnerability (permitting interrupt setup on un-owned devices). See XSA-237,
>which actually changed it in the opposite direction of what you're proposing.
Ok, I found it :
https://xenbits.xen.org/xsa/xsa237-4.5/0001-x86-dont
On 29/11/2019 12:19, Jan Beulich wrote:
> On 29.11.2019 13:15, Andrew Cooper wrote:
>> On 29/11/2019 12:13, Jan Beulich wrote:
>>> On 29.11.2019 13:01, Ian Jackson wrote:
Jan Beulich writes ("Re: [PATCH] console: avoid buffer overflow in
guest_console_write()"):
> On 29.11.2019 11:22
__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 all the Xen backend drivers missing
from the upstream kernel, and some of those out-of-tree drivers were
enabling interrupts in their eve
On Thu, Nov 28, 2019 at 04:52:24PM +, Paul Durrant wrote:
> From: George Dunlap
>
> Xen used to have single, system-wide limits for the number of grant
> frames and maptrack frames a guest was allowed to create. Increasing
> or decreasing this single limit on the Xen command-line would change
On Thu, Nov 28, 2019 at 04:52:24PM +, Paul Durrant wrote:
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 49b56fa1a3..a2a5d321c5 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -364,8 +364,8 @@
> */
> #define LIBXL_HAVE_BUILDINFO_GRANT_LIMITS 1
>
> -#de
> -Original Message-
> From: Anthony PERARD
> Sent: 29 November 2019 12:46
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; George Dunlap
> ; Ian Jackson ; Wei
> Liu ; Andrew Cooper ; George Dunlap
> ; Jan Beulich ; Julien
> Grall ; Konrad Rzeszutek Wilk ;
> Stefano Stabellini ;
On 29.11.2019 13:37, Andrew Cooper wrote:
> On 29/11/2019 12:19, Jan Beulich wrote:
>> On 29.11.2019 13:15, Andrew Cooper wrote:
>>> On 29/11/2019 12:13, Jan Beulich wrote:
On 29.11.2019 13:01, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] console: avoid buffer overflow in
> g
On 29.11.2019 13:34, DOZ, MARC (ext) wrote:
>
>> Except that this is not a "fix", but the introduction of a security
>> vulnerability (permitting interrupt setup on un-owned devices). See XSA-237,
>> which actually changed it in the opposite direction of what you're proposing.
>
> Ok, I found
On 29.11.19 14:26, Jan Beulich wrote:
On 29.11.2019 13:37, Andrew Cooper wrote:
On 29/11/2019 12:19, Jan Beulich wrote:
On 29.11.2019 13:15, Andrew Cooper wrote:
On 29/11/2019 12:13, Jan Beulich wrote:
On 29.11.2019 13:01, Ian Jackson wrote:
Jan Beulich writes ("Re: [PATCH] console: avoid bu
On 22.11.2019 11:31, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Wei
>> Liu
>> Sent: 21 November 2019 19:51
>> To: Xen Development List
>> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
>> ; Michael Kelley ; Jan
>> Beulich ; Roger Pau Monné
>> Subject: [Xen-devel]
On 22.11.2019 11:57, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Wei
>> Liu
>> Sent: 21 November 2019 19:51
>> To: Xen Development List
>> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
>> ; Michael Kelley ; Jan
>> Beulich ; Roger Pau Monné
>> Subject: [Xen-devel]
To prevent a module being removed whilst attached to a frontend, and
hence xenbus calling into potentially invalid text, take a reference on
the module before calling the probe() method (dropping it if unsuccessful)
and drop the reference after returning from the remove() method.
NOTE: This allows
Paul Durrant (2):
xen/xenbus: reference count registered modules
block/xen-blkback: allow module to be cleanly unloaded
drivers/block/xen-blkback/blkback.c | 8
drivers/block/xen-blkback/common.h | 3 +++
drivers/block/xen-blkback/xenbus.c | 11 +++
drivers/xen/xenbus/xen
On 21.11.2019 19:50, Wei Liu wrote:
> --- /dev/null
> +++ b/xen/arch/x86/guest/hypervisor.c
> @@ -0,0 +1,42 @@
> +/**
> + * arch/x86/guest/hypervisor.c
> + *
> + * Support for detecting and running under a hypervisor.
> + *
Add a module_exit() to perform the necessary clean-up.
Signed-off-by: Paul Durrant
---
Cc: Konrad Rzeszutek Wilk
Cc: "Roger Pau Monné"
Cc: Jens Axboe
v2:
- Drop the addition of ad-hoc reference counting as this is now done
centrally in xenbus
---
drivers/block/xen-blkback/blkback.c | 8
On 21.11.2019 19:50, Wei Liu wrote:
> +void __init hypervisor_setup(void)
> +{
> +if ( hops && hops->setup )
> +hops->setup();
> +}
> +
> +void hypervisor_ap_setup(void)
> +{
> +if ( hops && hops->ap_setup )
> +hops->ap_setup();
> +}
> +
> +void hypervisor_resume(void)
> +{
On Fri, Nov 29, 2019 at 12:51:47PM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Anthony PERARD
> > Sent: 29 November 2019 12:46
> > I'm not sure what was the intention with the new function
> > xlu_cfg_get_bounded_long(), but I don't think libxlu is the right place
> > for
On 29.11.2019 14:37, Jürgen Groß wrote:
> On 29.11.19 14:26, Jan Beulich wrote:
>> On 29.11.2019 13:37, Andrew Cooper wrote:
>>> On 29/11/2019 12:19, Jan Beulich wrote:
On 29.11.2019 13:15, Andrew Cooper wrote:
> On 29/11/2019 12:13, Jan Beulich wrote:
>> On 29.11.2019 13:01, Ian Jacks
On 29/11/2019 13:55, Jan Beulich wrote:
> On 29.11.2019 14:37, Jürgen Groß wrote:
>> On 29.11.19 14:26, Jan Beulich wrote:
>>> On 29.11.2019 13:37, Andrew Cooper wrote:
On 29/11/2019 12:19, Jan Beulich wrote:
> On 29.11.2019 13:15, Andrew Cooper wrote:
>> On 29/11/2019 12:13, Jan Beuli
On 29.11.19 14:55, Jan Beulich wrote:
On 29.11.2019 14:37, Jürgen Groß wrote:
On 29.11.19 14:26, Jan Beulich wrote:
On 29.11.2019 13:37, Andrew Cooper wrote:
On 29/11/2019 12:19, Jan Beulich wrote:
On 29.11.2019 13:15, Andrew Cooper wrote:
On 29/11/2019 12:13, Jan Beulich wrote:
On 29.11.20
> -Original Message-
> From: Anthony PERARD
> Sent: 29 November 2019 13:52
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; George Dunlap
> ; Ian Jackson ; Wei
> Liu ; Andrew Cooper ; George Dunlap
> ; Jan Beulich ; Julien
> Grall ; Konrad Rzeszutek Wilk ;
> Stefano Stabellini ;
conring_puts() has been requiring a nul-terminated string, which the
local kbuf[] doesn't get set for anymore. Add a length parameter to the
function, just like was done for others, thus allowing embedded nul to
also be read through XEN_SYSCTL_readconsole.
While there drop a stray cast: Both opera
Hi all,
Xen 4.13 rc4 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.13.0-rc4
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.13.0-rc4/xen-4.13.0-rc4.tar.gz
And the signature is at:
https://downloads.xenproject.org
On 29.11.19 15:15, Jan Beulich wrote:
conring_puts() has been requiring a nul-terminated string, which the
local kbuf[] doesn't get set for anymore. Add a length parameter to the
function, just like was done for others, thus allowing embedded nul to
also be read through XEN_SYSCTL_readconsole.
W
Hi,
On 29/11/2019 14:15, Jan Beulich wrote:
conring_puts() has been requiring a nul-terminated string, which the
local kbuf[] doesn't get set for anymore. Add a length parameter to the
function, just like was done for others, thus allowing embedded nul to
also be read through XEN_SYSCTL_readcons
On 21.11.2019 19:50, Wei Liu wrote:
> @@ -763,7 +764,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> * allocing any xenheap structures wanted in lower memory. */
> kexec_early_calculations();
>
> -hypervisor_probe();
> +running_on_hypervisor = !!hypervisor_probe();
From: George Dunlap
Xen used to have single, system-wide limits for the number of grant
frames and maptrack frames a guest was allowed to create. Increasing
or decreasing this single limit on the Xen command-line would change
the limit for all guests on the system.
Later, per-domain limits for t
On 29.11.2019 15:31, Jan Beulich wrote:
> On 21.11.2019 19:50, Wei Liu wrote:
>> @@ -763,7 +764,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>> * allocing any xenheap structures wanted in lower memory. */
>> kexec_early_calculations();
>>
>> -hypervisor_probe();
>> +
On 22.11.2019 12:11, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Wei
>> Liu
>> Sent: 21 November 2019 19:51
>> To: Xen Development List
>> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
>> ; Michael Kelley ; Jan
>> Beulich ; Roger Pau Monné
>> Subject: [Xen-devel]
Classify it as an XSA test (which arguably ought to be named 'security'),
despite no XSA being issues.
Signed-off-by: Andrew Cooper
---
docs/all-tests.dox | 2 ++
tests/xsa-consoleio-write/Makefile | 9 +
tests/xsa-consoleio-write/main.c | 69 +
On Fri, Nov 29, 2019 at 12:12:51PM +, Andrew Cooper wrote:
> On 29/11/2019 12:09, Jan Beulich wrote:
> > On 25.11.2019 18:22, Roger Pau Monne wrote:
> >> When using global pages a full tlb flush can only be performed by
> >> toggling the PGE bit in CR4, which is usually quite expensive in terms
On 29.11.2019 15:35, Andrew Cooper wrote:
> Classify it as an XSA test (which arguably ought to be named 'security'),
> despite no XSA being issues.
Nit: issued
> Signed-off-by: Andrew Cooper
FWIW
Reviewed-by: Jan Beulich
with a remark and a question:
> --- a/docs/all-tests.dox
> +++ b/docs/a
On 29.11.2019 15:43, Jan Beulich wrote:
> On 29.11.2019 15:35, Andrew Cooper wrote:
>> Classify it as an XSA test (which arguably ought to be named 'security'),
>> despite no XSA being issues.
>
> Nit: issued
>
>> Signed-off-by: Andrew Cooper
>
> FWIW
> Reviewed-by: Jan Beulich
> with a remark
On 29.11.2019 15:36, Roger Pau Monné wrote:
> On Fri, Nov 29, 2019 at 12:12:51PM +, Andrew Cooper wrote:
>> I agree that this wants a command line control, but it wants to be
>> enabled by default any time we find ourselves nested on AMD hardware,
>> not just in shim.
>
> Only on AMD hardware
There were some hard tabs here. Replace them with 8 spaces.
(I noticed this because my release technician work involves
untabifying this file.)
Signed-off-by: Ian Jackson
---
README | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/README b/README
index eab6bfea8a..92b1de
On 29/11/2019 14:45, Jan Beulich wrote:
> On 29.11.2019 15:43, Jan Beulich wrote:
>> On 29.11.2019 15:35, Andrew Cooper wrote:
>>> Classify it as an XSA test (which arguably ought to be named 'security'),
>>> despite no XSA being issues.
>> Nit: issued
Will fix.
>>
>>> Signed-off-by: Andrew Coope
On Fri, Nov 29, 2019 at 01:43:06PM +, Paul Durrant wrote:
> Add a module_exit() to perform the necessary clean-up.
>
> Signed-off-by: Paul Durrant
LGTM:
Reviewed-by: Roger Pau Monné
AFAICT we should make sure this is not committed before patch 1, or
else you could unload a blkback module
> -Original Message-
> From: Roger Pau Monné
> Sent: 29 November 2019 15:00
> To: Durrant, Paul
> Cc: linux-bl...@vger.kernel.org; linux-ker...@vger.kernel.org; xen-
> de...@lists.xenproject.org; Konrad Rzeszutek Wilk
> ; Jens Axboe
> Subject: Re: [PATCH v2 2/2] block/xen-blkback: allow
It is only necessary to change Config.mk if it refers to unstable
branches anywhere. This time, for example, it didn't.
Signed-off-by: Ian Jackson
---
docs/process/branching-checklist.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/process/branching-checklist.txt
b/docs/process/br
The release technician has not been responsible for website updates
for some time.
Signed-off-by: Ian Jackson
---
docs/process/release-technician-checklist.txt | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/docs/process/release-technician-checklist.txt
b/docs/process/re
We no longer use hg
Signed-off-by: Ian Jackson
---
docs/process/branching-checklist.txt | 4
1 file changed, 4 deletions(-)
diff --git a/docs/process/branching-checklist.txt
b/docs/process/branching-checklist.txt
index 5a02d21968..4cda33656d 100644
--- a/docs/process/branching-checklist.t
One per line is a lot easier to read.
Signed-off-by: Ian Jackson
---
docs/process/release-technician-checklist.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/docs/process/release-technician-checklist.txt
b/docs/process/release-technician-checklist.txt
index 5dd85dbc
I have a growing branch of patches to the release process docs. These
should go into tree.
As the release technican I am going to commit these (to staging, which
is the one we use for everything) unless someone clearly naks them.
If you want to improve the process, patches to these files (etc.) a
This should be done not while branching, but right after .0 is
released.
Signed-off-by: Ian Jackson
---
docs/process/branching-checklist.txt | 7 ---
docs/process/release-technician-checklist.txt | 8
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/docs/proce
Provide a rune, following which a magit selective git add
(or git add -p) can be used to commit the appropriate changes.
Signed-off-by: Ian Jackson
---
docs/process/branching-checklist.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/docs/process/branching-checklist.txt
b/docs/process/
Signed-off-by: Ian Jackson
---
docs/process/release-technician-checklist.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/docs/process/release-technician-checklist.txt
b/docs/process/release-technician-checklist.txt
index 72a4c36cd6..5bce5ba63d 100644
--- a/docs/process/release-technici
Hi,
On 27/11/2019 18:44, Pavel Tatashin wrote:
diff --git a/arch/arm64/include/asm/xen/hypercall.h
b/arch/arm64/include/asm/xen/hypercall.h
index 3522cbaed316..1a74fb28607f 100644
--- a/arch/arm64/include/asm/xen/hypercall.h
+++ b/arch/arm64/include/asm/xen/hypercall.h
@@ -1 +1,29 @@
+#ifndef _
The version number is not in the "heading".
Signed-off-by: Ian Jackson
---
docs/process/release-technician-checklist.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/process/release-technician-checklist.txt
b/docs/process/release-technician-checklist.txt
index f4bee4
In particular, say clearly that X.Y-unstable should be thus, not
X.Y.0-unstable.
CC: Jan Beulich
Signed-off-by: Ian Jackson
---
docs/process/release-technician-checklist.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/docs/process/release-technician-checklist.txt
b
On Fri, Nov 29, 2019 at 03:02:37PM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Roger Pau Monné
> > Sent: 29 November 2019 15:00
> > To: Durrant, Paul
> > Cc: linux-bl...@vger.kernel.org; linux-ker...@vger.kernel.org; xen-
> > de...@lists.xenproject.org; Konrad Rzeszutek W
On 29/11/2019 15:05, Julien Grall wrote:
> Hi,
>
> On 27/11/2019 18:44, Pavel Tatashin wrote:
>> diff --git a/arch/arm64/include/asm/xen/hypercall.h
>> b/arch/arm64/include/asm/xen/hypercall.h
>> index 3522cbaed316..1a74fb28607f 100644
>> --- a/arch/arm64/include/asm/xen/hypercall.h
>> +++ b/arch/a
On 29.11.2019 15:48, Ian Jackson wrote:
> There were some hard tabs here. Replace them with 8 spaces.
>
> (I noticed this because my release technician work involves
> untabifying this file.)
>
> Signed-off-by: Ian Jackson
In case one is needed:
Acked-by: Jan Beulich
___
On 29.11.2019 16:04, Ian Jackson wrote:
> In particular, say clearly that X.Y-unstable should be thus, not
> X.Y.0-unstable.
>
> CC: Jan Beulich
> Signed-off-by: Ian Jackson
Oh, I didn't even realize this wasn't written down anywhere.
Thanks for making explicit.
Acked-by: Jan Beulich
Jan
__
Xen 4.13 has been branched. So the staging branch is open again for
development.
BUT: please bear in mind that we have no 4.13 release yet, so there
might be the need to push further corrections to 4.13-staging before we
can release. For that reason please don't commit patches which will make
suc
1 - 100 of 135 matches
Mail list logo
