flight 144380 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144380/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 138829
flight 144376 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144376/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
On 11/29/19 7:39 AM, 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 all the Xen backend drivers missing
> from the upstream kernel, and some of those
On 11/13/19 10:55 PM, Julian Tuminaro wrote:
From: Julian Tuminaro and Jenish Rakholiya
Current implementation of find_os is based on the hard-coded values for
different Windows version. It uses the value for get the address to
start looking for DOS header in the given specified range.
flight 144400 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144400/
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
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 144399 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144399/
Failures
On Fri, Nov 29, 2019 at 10:15:33PM +0100, Marek Marczykowski-Górecki wrote:
> On Fri, Nov 29, 2019 at 05:44:23PM +, Wei Liu wrote:
> > On Fri, Nov 29, 2019 at 05:36:11PM +, Wei Liu wrote:
> > > On Fri, Nov 29, 2019 at 05:24:45PM +, Paul Durrant wrote:
> > > > From: George Dunlap
> > >
flight 144398 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144398/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Fri, Nov 29, 2019 at 05:44:23PM +, Wei Liu wrote:
> On Fri, Nov 29, 2019 at 05:36:11PM +, Wei Liu wrote:
> > On Fri, Nov 29, 2019 at 05:24:45PM +, Paul Durrant wrote:
> > > From: George Dunlap
> > >
> > > Xen used to have single, system-wide limits for the number of grant
> > >
If the feature is not present Xen will try to force X86_BUG_FPU_PTRS
feature at CPU identification time. This is especially noticeable in
PV-shim that usually hotplugs its vCPUs. We either need to restrict this
action for boot CPU only or allow secondary CPUs to modify
forced CPU capabilities at
On 14/11/2019 08:27, Juergen Gross wrote:
> Gdbsx support in the hypervisor is rarely used and it is opening a
> way for dom0 to modify the running hypervisor by very easy means.
>
> Add a Kconfig option to control support of gdbsx. Default is off.
This would constitute a regression, and I (and
On 14/11/2019 08:27, Juergen Gross wrote:
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 9f7bc69293..d2d30ece7d 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -652,7 +652,11 @@ void domain_destroy(struct domain *d);
> int domain_kill(struct
On 22/11/2019 11:22, Durrant, Paul wrote:
>> @@ -1144,27 +1140,22 @@ map_grant_ref(
>> if ( need_iommu )
>> {
>> unsigned int kind;
>> -int err = 0;
>>
>> double_gt_lock(lgt, rgt);
>>
>> -/* We're not translated, so we know that gmfns and mfns are
>> -
On Fri, Nov 29, 2019 at 05:53:39PM +, George Dunlap wrote:
>
>
> > On Nov 29, 2019, at 5:44 PM, Wei Liu wrote:
> >
> > On Fri, Nov 29, 2019 at 05:36:11PM +, Wei Liu wrote:
> >> On Fri, Nov 29, 2019 at 05:24:45PM +, Paul Durrant wrote:
> >>> From: George Dunlap
> >>>
> >>> Xen
On 21/11/2019 18:50, Wei Liu wrote:
> Also replace xen_guest with running_on_hypervisor boolean.
I agree with dropping xen_guest, but...
>
> Signed-off-by: Wei Liu
> ---
> Changes in v4:
> 1. Access ->name directly.
> 2. Drop Roger's review tag.
> ---
> xen/arch/x86/setup.c | 7 +--
> 1
On 21/11/2019 18:50, Wei Liu wrote:
> +#include
> +
> +#include
> +#include
> +
> +static const struct hypervisor_ops __read_mostly *hops;
Could I talk you into using just plain 'ops' here. This is mostly
plumbing and doesn't appear to grow significantly. I don't think there
is a risk of
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 144390 xen-4.13-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/144390/
Failures
> On Nov 29, 2019, at 5:44 PM, Wei Liu wrote:
>
> On Fri, Nov 29, 2019 at 05:36:11PM +, Wei Liu wrote:
>> On Fri, Nov 29, 2019 at 05:24:45PM +, Paul Durrant wrote:
>>> From: George Dunlap
>>>
>>> Xen used to have single, system-wide limits for the number of grant
>>> frames and
flight 144388 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144388/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Fri, Nov 29, 2019 at 05:36:11PM +, Wei Liu wrote:
> On Fri, Nov 29, 2019 at 05:24:45PM +, 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
>
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 144386 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144386/
Failures
On Fri, Nov 29, 2019 at 05:24:45PM +, 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
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
c/s d0a699a389f1 "x86/monitor: add support for descriptor access events"
introduced logic looking for what appeared to be exitinfo (not that this
exists in SVM - exitinfo1 or 2 do), but actually passed the exit IDT vectoring
information. There is never any IDT vectoring involved in these
Ian Jackson writes ("RE: [PATCH-for-4.13 v5] Rationalize max_grant_frames and
max_maptrack_frames handling"):
> I think our proposal is to drop the type change, continue to use
> uint32_t everwhere for these values, and specify the "use default"
> value to be all-bits-set.
Following discussion
> -Original Message-
> From: Ian Jackson
> Sent: 29 November 2019 16:08
> To: Durrant, Paul
> Cc: Wei Liu ; Anthony Perard ; xen-
> de...@lists.xenproject.org; George Dunlap ;
> Andrew Cooper ; Jan Beulich
> ; Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ;
> Marek
> On Nov 29, 2019, at 4:07 PM, Ian Jackson wrote:
>
> Durrant, Paul writes ("RE: [PATCH-for-4.13 v5] Rationalize max_grant_frames
> and max_maptrack_frames handling"):
>>> -Original Message-
>>> From: Ian Jackson
> ...
>>> Is there some reason we wouldn't use ~0 to mean default ?
>>>
> -Original Message-
> From: Jan Beulich
> Sent: 29 November 2019 16:01
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; linux-bl...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Stefano Stabellini ; Boris
> Ostrovsky ; Juergen Gross
> Subject: Re: [PATCH v2 1/2]
Durrant, Paul writes ("RE: [PATCH-for-4.13 v5] Rationalize max_grant_frames and
max_maptrack_frames handling"):
> > -Original Message-
> > From: Ian Jackson
...
> > Is there some reason we wouldn't use ~0 to mean default ?
> >
> > In the tools area we normally spell this as
> >
On 29.11.2019 14:43, Paul Durrant wrote:
> To prevent a module being removed whilst attached to a frontend, and
Why only frontend?
> 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
> -Original Message-
> From: Ian Jackson
> Sent: 29 November 2019 15:47
> To: Wei Liu
> Cc: Durrant, Paul ; Anthony Perard
> ; xen-devel@lists.xenproject.org; George Dunlap
> ; Andrew Cooper ; Jan
> Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Marek
Wei Liu writes ("Re: [PATCH-for-4.13 v5] Rationalize max_grant_frames and
max_maptrack_frames handling"):
> What if we use 0x to denote default instead? That wouldn't
> require changing the type here.
Is there some reason we wouldn't use ~0 to mean default ?
In the tools area we
On 29.11.19 14:43, Paul Durrant wrote:
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
On 29.11.19 16:07, Roger Pau Monné wrote:
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-
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
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
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 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
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
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
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
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
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
---
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
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
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.)
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
---
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
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
> -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
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
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
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
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
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
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
> +++
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
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 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:
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();
>> +
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
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 =
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
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.
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:
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
> -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 ;
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
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
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
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 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)
> +{
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
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
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 +++
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.
> +
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:
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:
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
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
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
>
> -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 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
>
>
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
__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
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
>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 :
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
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
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 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
> -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:
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()
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 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: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
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
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 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
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.
1 - 100 of 133 matches
Mail list logo
