On 21.11.19 08:30, Steven Haigh wrote:
On 2019-11-21 17:05, Jürgen Groß wrote:
Where do we stand with Xen 4.13 regarding blockers and related patches?
2. Ryzen/Rome failures with Windows guests:
What is the currently planned way to address the problem? Who is
working on that?
A workarou
On 2019-11-21 17:05, Jürgen Groß wrote:
Where do we stand with Xen 4.13 regarding blockers and related patches?
2. Ryzen/Rome failures with Windows guests:
What is the currently planned way to address the problem? Who is
working on that?
A workaround was found by specifying cpuid values
It helps to distinguish parked CPUs from those are really offlined or
hot-added. We need to know the parked CPUs in order to do a special
check against them to ensure that all CPUs, except those are really
offlined or hot-added, have the same ucode version.
Signed-off-by: Chao Gao
---
Note that c
If a core with all of its thread being parked, late ucode loading
which currently only loads ucode on online threads would lead to
differing ucode revisions in the system. In general, keeping ucode
revision consistent would be less error-prone. To this end, if there
is a parked thread doesn't have
flight 144226 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144226/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144025
Tests
Where do we stand with Xen 4.13 regarding blockers and related patches?
1. OSStest failure regarding nested test:
I'm not quite sure whether the currently debated patch of Andrew is
fixing the problem. If not, do we know what is missing or how to
address the issue? If yes, could we pleas
On 20.11.19 18:54, Ian Jackson wrote:
Hi, I promised you to do a risk/benefit analysis on this series and
here is my report. With your permission I plan to push it on Sunday
night or Monday morning, if you think that is a convenient time.
TYVM.
I'm fine with your plan.
Juergen
Summary:
flight 144222 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144222/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144042
Regression
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Fix also 7-space and tab+1 space indentation issues.
---
arch/x86/Kconfig | 68
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Fix also 7-space and tab+1 space indentation issues.
---
drivers/xen/Kconfig | 58 +
On Wed, 20 Nov 2019 at 22:02, Jan Beulich wrote:
>
> On 20.11.2019 14:38, Krzysztof Kozlowski wrote:
> > Adjust indentation from spaces to tab (+optional two spaces) as in
> > coding style with command like:
> > $ sed -e 's/^/\t/' -i */Kconfig
> >
> > Signed-off-by: Krzysztof Kozlows
> Yes, this hunk is missing (somehow it did not make it to the v5 patchset,
> sorry):
>
> diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
> index 7747ea83aa..0b21a6aca4 100644
> --- a/tools/libxc/xc_misc.c
> +++ b/tools/libxc/xc_misc.c
> @@ -976,6 +976,7 @@ static int _xc_livepatch_act
flight 144224 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144224/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bf1ea933ec1c6447c4168c34cc1b7ea4ac8f3e4d
baseline version:
ovmf 7607174192166dd5d2d69
On Thu, 14 Nov 2019, Andrii Anisov wrote:
> On 11.11.19 23:26, Stefano Stabellini wrote:
>
> > Why _srodata and __start_bug_frames cannot both be defined as
> > Load$$_rodata_bug_frames_0$$Base when actually in the case of:
> >
> > > +#define __per_cpu_data_end Load$$_bss_percpu$$Limit
>
On Thu, 14 Nov 2019, Andrii Anisov wrote:
> Hello Stefano,
>
> On 11.11.19 22:59, Stefano Stabellini wrote:
> > this seems a very serious compiler bug.
>
> Yep.
>
> > This, together with the other bug described in the previous patch, makes
> > me think the ARMCC is not quite ready for showtime.
+ fusa-sig
On Thu, 14 Nov 2019, Artem Mygaiev wrote:
> Hello Julien
>
> On Thu, 2019-11-14 at 08:03 +0900, Julien Grall wrote:
> >
> >
> > On Tue, 12 Nov 2019, 05:57 Stefano Stabellini, <
> > sstabell...@kernel.org> wrote:
> > > On Wed, 6 Nov 2019, Andrii Anisov wrote:
> > > > From: Andrii Anis
On Wed, 13 Nov 2019, Julien Grall wrote:
> On Tue, 12 Nov 2019, 05:52 Stefano Stabellini, wrote:
> On Wed, 6 Nov 2019, Andrii Anisov wrote:
> > From: Andrii Anisov
> >
> > Also armclang complains about the condition always true,
> > because `sgi` is of type enum with
flight 144218 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144218/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR.
vs. 144209
test-amd
Hi Jan,
On 14/11/2019 16:43, Jan Beulich wrote:
In order for individual IOMMU drivers (and from an abstract pov also
architectures) to be able to adjust, ahead of actual mapping requests,
their data structures when they might cover only a sub-range of all
possible GFNs, introduce a notification
flight 144216 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144216/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144035
Tests
flight 144227 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144227/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 20/11/2019 17:19, Jan Beulich wrote:
> On 20.11.2019 18:13, Andrew Cooper wrote:
>> On 20/11/2019 16:40, Jürgen Groß wrote:
>>> On 20.11.19 17:30, Jan Beulich wrote:
On 08.11.2019 12:18, Jan Beulich wrote:
> The .file assembler directives generated by the compiler do not include
> a
Hi, I promised you to do a risk/benefit analysis on this series and
here is my report. With your permission I plan to push it on Sunday
night or Monday morning, if you think that is a convenient time.
Summary:
There are three kinds of risk here:
* There is a nonneglible chance that these chang
Current code unconditionally prevents setting APIC_SPIV_FOCUS_DISABLED
regardless of the processor model, which is not correct according to
the specification.
Fix it by allowing setting APIC_SPIV_FOCUS_DISABLED based on the
domain cpuid policy.
Signed-off-by: Roger Pau Monné
---
Cc: Juergen Gros
On 20.11.2019 18:13, Andrew Cooper wrote:
> On 20/11/2019 16:40, Jürgen Groß wrote:
>> On 20.11.19 17:30, Jan Beulich wrote:
>>> On 08.11.2019 12:18, Jan Beulich wrote:
The .file assembler directives generated by the compiler do not include
any path components (gcc) or just the ones speci
On 02.10.2019 19:16, Hongyan Xia wrote:
> From: Wei Liu
>
> We will need to have a variable named pl*e when we rewrite
> virt_to_xen_l*e. Change pl*e to l*t to reflect better its purpose.
> This will make reviewing later patch easier.
>
> No functional change.
>
> Signed-off-by: Wei Liu
> Sign
On 20/11/2019 16:40, Jürgen Groß wrote:
> On 20.11.19 17:30, Jan Beulich wrote:
>> On 08.11.2019 12:18, Jan Beulich wrote:
>>> The .file assembler directives generated by the compiler do not include
>>> any path components (gcc) or just the ones specified on the command
>>> line
>>> (clang, at leas
On 20.11.19 17:30, Jan Beulich wrote:
On 08.11.2019 12:18, Jan Beulich wrote:
The .file assembler directives generated by the compiler do not include
any path components (gcc) or just the ones specified on the command line
(clang, at least version 5), and hence multiple identically named source
On 08.11.2019 12:18, Jan Beulich wrote:
> The .file assembler directives generated by the compiler do not include
> any path components (gcc) or just the ones specified on the command line
> (clang, at least version 5), and hence multiple identically named source
> files (in different directories)
On 02.10.2019 19:16, Hongyan Xia wrote:
> @@ -5468,7 +5469,11 @@ int modify_xen_mappings(unsigned long s, unsigned long
> e, unsigned int nf)
> /* PAGE1GB: shatter the superpage and fall through. */
> l2t = alloc_xen_pagetable();
> if ( !l2t )
> -
On 02.10.2019 19:16, Hongyan Xia wrote:
> @@ -5034,10 +5036,13 @@ int map_pages_to_xen(
>
> while ( nr_mfns != 0 )
> {
> -l3_pgentry_t ol3e, *pl3e = virt_to_xen_l3e(virt);
> +pl3e = virt_to_xen_l3e(virt);
>
> if ( !pl3e )
> -return -ENOMEM;
> +
On 02.10.2019 19:16, Hongyan Xia wrote:
> From: Wei Liu
>
> The pl2e and pl1e variables are heavily (ab)used in that function. It
> is fine at the moment because all page tables are always mapped so
> there is no need to track the life time of each variable.
>
> We will soon have the requiremen
On 02.10.2019 19:16, Hongyan Xia wrote:
> From: Wei Liu
>
> The pl2e and pl1e variables are heavily (ab)used in that function. It
> is fine at the moment because all page tables are always mapped so
> there is no need to track the life time of each variable.
>
> We will soon have the requirement
Oleksandr Grytsov writes ("Re: [PATCH for-4.13 v1 1/2] libxl: introduce new
backend type VINPUT"):
> I will submit V2 with renaming and comments addressed for second commit [3]
> of the patchset.
Thanks. Juergen tells this is OK in principle but me he wants to take
only critical fixes after the
On 20/11/2019 15:49, Jürgen Groß wrote:
> On 15.11.19 19:59, Igor Druzhinin wrote:
>> From: Paul Durrant
>>
>> Dropping the pcidevs lock between calling device_assigned() and
>> assign_device() means that the latter has to do the same check as the
>> former for no obvious gain. Also, since long ru
flight 144225 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144225/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 20.11.19 08:50, Jan Beulich wrote:
On 19.11.2019 18:58, Anthony PERARD wrote:
Following the patch 65d104984c04 ("x86: fix race to build
arch/x86/efi/relocs-dummy.o"), the error message
nm: 'efi/relocs-dummy.o': No such file"
started to appear on system which can't build the .efi target. Th
On 15.11.19 19:59, Igor Druzhinin wrote:
From: Paul Durrant
Dropping the pcidevs lock between calling device_assigned() and
assign_device() means that the latter has to do the same check as the
former for no obvious gain. Also, since long running operations under
pcidevs lock already drop the l
On Fri, Oct 11, 2019 at 07:04:17PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
> --- a/hw/block/xen-block.c
> +++ b/hw/block/xen-block.c
> @@ -915,15 +903,15 @@ static void xen_block_device_create(XenBackendInstance
> *backend,
> g
flight 144212 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144212/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144025
Tests
On 20.11.19 15:06, Andrew Cooper wrote:
On 20/11/2019 13:56, Jan Beulich wrote:
On 20.11.2019 14:37, Julien Grall wrote:
From: Julien Grall
The documentation requires va_start() to always be matched with a
corresponding va_end(). However, this is not the case in the path used
for bad format.
flight 144215 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144215/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144165
test-armhf-armhf-libvirt-raw 13 saveresto
On 20/11/2019 13:56, Jan Beulich wrote:
> On 20.11.2019 14:37, Julien Grall wrote:
>> From: Julien Grall
>>
>> The documentation requires va_start() to always be matched with a
>> corresponding va_end(). However, this is not the case in the path used
>> for bad format.
>>
>> This was introduced by
On 20.11.2019 14:38, Krzysztof Kozlowski wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^/\t/' -i */Kconfig
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/xen/Kconfig | 22 +++---
>
On 20.11.2019 14:37, Julien Grall wrote:
> From: Julien Grall
>
> The documentation requires va_start() to always be matched with a
> corresponding va_end(). However, this is not the case in the path used
> for bad format.
>
> This was introduced by XSA-296.
>
> Coverity-ID: 1488727
> Fixes: 0b
On 20.11.2019 13:08, Paul Durrant wrote:
> This patch introduces a new iommu_op to facilitate a per-implementation
> quarantine set up, and then further code for x86 implementations
> (amd and vtd) to set up a read/wrote scratch page to serve as the source/
> target for all DMA whilst a device is a
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
drivers/xen/Kconfig | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
From: Julien Grall
The documentation requires va_start() to always be matched with a
corresponding va_end(). However, this is not the case in the path used
for bad format.
This was introduced by XSA-296.
Coverity-ID: 1488727
Fixes: 0bf9f8d3e3 ("xen/hypercall: Don't use BUG() for parameter check
Am 20.11.2019 um 13:59 hat Eric Blake geschrieben:
> On 11/20/19 3:50 AM, Vladimir Sementsov-Ogievskiy wrote:
> > Okay...
> >
> > I think that:
> >
> > 1. A lot of efforts (not only my, I think reviewing is already exceeded
> > generation efforts)
> > are made, it would be sad to lose them.
On 11/20/19 3:50 AM, Vladimir Sementsov-Ogievskiy wrote:
Okay...
I think that:
1. A lot of efforts (not only my, I think reviewing is already exceeded
generation efforts)
are made, it would be sad to lose them.
2. It's safe enough to apply only part of generated patches: we just fix
erro
flight 144221 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144221/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
This patch introduces a new iommu_op to facilitate a per-implementation
quarantine set up, and then further code for x86 implementations
(amd and vtd) to set up a read/wrote scratch page to serve as the source/
target for all DMA whilst a device is assigned to dom_io.
The reason for doing this is
> -Original Message-
> From: Jan Beulich
> Sent: 20 November 2019 12:42
> To: Durrant, Paul
> Cc: Roger Pau Monné ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] grant table size
>
> On 20.11.2019 12:18, Durrant, Paul wrote:
> >> -Original Message-
> >> From: Jan Be
On 19/11/2019 17:21, Wieczorkiewicz, Pawel wrote:
>
>
>> On 18. Nov 2019, at 18:41, Sergey Dyasli wrote:
>>
>> On 18/11/2019 17:28, Wieczorkiewicz, Pawel wrote:
>>>
>>> Could you build the lp with debug (-d) and provide me with the
>>> create-diff-object.log file?
>>>
>>
>> I've attached the lo
On 20.11.2019 12:18, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 20 November 2019 12:09
>> To: Durrant, Paul
>> Cc: Roger Pau Monné ; xen-devel@lists.xenproject.org
>> Subject: Re: [Xen-devel] grant table size
>>
>> On 20.11.2019 11:49, Durrant, Paul wrote
flight 144214 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144214/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7607174192166dd5d2d6913fc2fdb8ce539cd3c9
baseline version:
ovmf 0b9ad0bc030bbd79073a2
flight 144211 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144211/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144042
test-amd64
> -Original Message-
> From: Jan Beulich
> Sent: 20 November 2019 12:09
> To: Durrant, Paul
> Cc: Roger Pau Monné ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] grant table size
>
> On 20.11.2019 11:49, Durrant, Paul wrote:
> >> From: Roger Pau Monné
> >> Sent: 20 Novembe
On 20.11.2019 11:49, Durrant, Paul wrote:
>> From: Roger Pau Monné
>> Sent: 20 November 2019 11:06
>>
>> Do you have in mind to signal this somehow to guests, or the
>> expectation is that the guest will have to poll GNTTABOP_query_size
>> and at some point the size will increase?
>
> I don't t
> -Original Message-
> From: Roger Pau Monné
> Sent: 20 November 2019 11:06
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] grant table size
>
> On Wed, Nov 20, 2019 at 09:43:59AM +, Durrant, Paul wrote:
> > I've dealt with a few problems over the
On Wed, Nov 20, 2019 at 11:41:24AM +0100, Jürgen Groß wrote:
> On 15.11.19 17:15, Anthony PERARD wrote:
> > https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
> >
> > > To embed Python into an application, a new --embed option must be
> > > passed to pytho
On 15.11.19 17:15, Anthony PERARD wrote:
https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
To embed Python into an application, a new --embed option must be
passed to python3-config --libs --embed to get -lpython3.8 (link the
application to libpython).
On Fri, Nov 15, 2019 at 04:22:15PM +, Wei Liu wrote:
> On Fri, Nov 15, 2019 at 04:15:32PM +, Anthony PERARD wrote:
> > https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
> >
> > > To embed Python into an application, a new --embed option must be
>
Okay...
I think that:
1. A lot of efforts (not only my, I think reviewing is already exceeded
generation efforts)
are made, it would be sad to lose them.
2. It's safe enough to apply only part of generated patches: we just fix
error_abort/error_fatal
in more popular subsystems, what's wr
flight 144220 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144220/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 0273d8e24249d14f5964f6b2193a53a1fb99ce9e
baseline version:
xen b92a
On Wed, Nov 20, 2019 at 09:43:59AM +, Durrant, Paul wrote:
> I've dealt with a few problems over the years where the root cause was a
> guest running out of grant table and so I'm wondering whether it would be a
> good idea to allow a toolstack to increase the table size of a running guest,
> On 20. Nov 2019, at 03:25, Konrad Rzeszutek Wilk
> wrote:
>
> On Thu, Nov 14, 2019 at 01:06:41PM +, Pawel Wieczorkiewicz wrote:
>> This series introduces new features to the livepatch functionality as
>> briefly discussed during Xen Developer Summit 2019: [a] and [b].
>> It also provides
I've dealt with a few problems over the years where the root cause was a guest
running out of grant table and so I'm wondering whether it would be a good idea
to allow a toolstack to increase the table size of a running guest, e.g. when
plugging in a new PV interface.
It would appear that curren
On 20.11.2019 10:41, Jan Beulich wrote:
> On 20.11.2019 09:29, Alexandru Stefan ISAILA wrote:
>> On 19.11.2019 11:23, Jan Beulich wrote:
>>> On 19.11.2019 10:05, Alexandru Stefan ISAILA wrote:
On 18.11.2019 16:09, Jan Beulich wrote:
> On 18.11.2019 14:39, Alexandru Stefan ISAILA wrote:
>
On 20.11.2019 09:29, Alexandru Stefan ISAILA wrote:
> On 19.11.2019 11:23, Jan Beulich wrote:
>> On 19.11.2019 10:05, Alexandru Stefan ISAILA wrote:
>>> On 18.11.2019 16:09, Jan Beulich wrote:
On 18.11.2019 14:39, Alexandru Stefan ISAILA wrote:
> For this HVMOP_ALTP2M_INTERFACE_VERSION sho
On 19.11.2019 15:58, Andrew Cooper wrote:
> On 19/11/2019 11:13, Jan Beulich wrote:
>> On 18.11.2019 19:15, Andrew Cooper wrote:
>>> @@ -181,6 +180,18 @@ nestedhap_walk_L0_p2m(struct p2m_domain *p2m, paddr_t
>>> L1_gpa, paddr_t *L0_gpa,
>>> *L0_gpa = (mfn_x(mfn) << PAGE_SHIFT) + (L1_gpa & ~PA
On 19.11.2019 21:45, Andrew Cooper wrote:
> On 19/11/2019 15:23, Jan Beulich wrote:
>> On 19.11.2019 15:58, Andrew Cooper wrote:
>>> On 19/11/2019 11:13, Jan Beulich wrote:
On 18.11.2019 19:15, Andrew Cooper wrote:
I take it you imply that L0_ERROR would need raising (as per the
auxi
On 19.11.2019 11:23, Jan Beulich wrote:
> On 19.11.2019 10:05, Alexandru Stefan ISAILA wrote:
>> On 18.11.2019 16:09, Jan Beulich wrote:
>>> On 18.11.2019 14:39, Alexandru Stefan ISAILA wrote:
For this HVMOP_ALTP2M_INTERFACE_VERSION shout be increased. I will leave
it to Tamas to decide i
73 matches
Mail list logo
