flight 161201 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161201/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 161125
test-amd64-i386-xl-qemut-win7-amd64 19
flight 161198 xen-unstable real [real]
flight 161221 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161198/
http://logs.test-lab.xenproject.org/osstest/logs/161221/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-win7-amd64
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
flight 161196 xen-4.12-testing real [real]
flight 161214 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161196/
http://logs.test-lab.xenproject.org/osstest/logs/161214/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
Hi Stefano,
On 13/04/2021 23:43, Stefano Stabellini wrote:
On Sat, 20 Mar 2021, Julien Grall wrote:
On 20/03/2021 00:01, Stefano Stabellini wrote:
On Sat, 27 Feb 2021, Julien Grall wrote:
(+ Dario and George)
Hi Stefano,
I have added Dario and George to get some inputs from the scheduling
flight 161209 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161209/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi Julien
> On 16 Apr 2021, at 5:08 pm, Julien Grall wrote:
>
>
>
> On 16/04/2021 17:05, Rahul Singh wrote:
>>> On 16 Apr 2021, at 4:23 pm, Julien Grall wrote:
>>>
>>>
>>>
>>> On 16/04/2021 16:01, Rahul Singh wrote:
Hi Julien,
>>>
>>> Hi Rahul,
>>>
> On 16 Apr 2021, at 3:35 pm,
On 16/04/2021 17:05, Rahul Singh wrote:
On 16 Apr 2021, at 4:23 pm, Julien Grall wrote:
On 16/04/2021 16:01, Rahul Singh wrote:
Hi Julien,
Hi Rahul,
On 16 Apr 2021, at 3:35 pm, Julien Grall wrote:
Hi,
On 16/04/2021 12:25, Rahul Singh wrote:
Revert the code that associates the
Hi Julein
> On 16 Apr 2021, at 4:23 pm, Julien Grall wrote:
>
>
>
> On 16/04/2021 16:01, Rahul Singh wrote:
>> Hi Julien,
>
> Hi Rahul,
>
>>> On 16 Apr 2021, at 3:35 pm, Julien Grall wrote:
>>>
>>> Hi,
>>>
>>> On 16/04/2021 12:25, Rahul Singh wrote:
Revert the code that associates
Hi Julien,
> On 5 Apr 2021, at 17:20, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, we are computing offsets/masks for each level and
> granularity. This is a bit of waste given that we only need to
> know the offsets/masks for the granularity used by the guest.
>
> All the
This hunk was missing from the work to drop gettext as a build dependency.
Fixes: e21a6a4f96 ("tools: Drop gettext as a build dependency")
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei Liu
CC: Roger Pau Monné
CC: Julien
Thanks @Andrew,
A LKM to dump the arch->p2m_vaddr solved the issue and answered my
questions!
Atenciosamente,
*Charles Ferreira Gonçalves *
On Fri, Apr 16, 2021 at 4:12 PM Andrew Cooper
wrote:
> On 16/04/2021 15:58, Charles Gonçalves wrote:
>
> Hello Guys,
>
> Does memory on Dom0 also
flight 161191 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161191/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
On 16/04/2021 16:01, Rahul Singh wrote:
Hi Julien,
Hi Rahul,
On 16 Apr 2021, at 3:35 pm, Julien Grall wrote:
Hi,
On 16/04/2021 12:25, Rahul Singh wrote:
Revert the code that associates the group pointer with the S2CR as this
code causing an issue when the SMMU device has more than
flight 161206 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161206/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 16/04/2021 15:58, Charles Gonçalves wrote:
>
> Hello Guys,
>
> Does memory on Dom0 also mapped to gpfn or it is mapped directly to mfn?
>
> If mapped to gpfn, how can I access its p2m mapping?
>
> I'm trying to use the xen-mfndump but it is not working with dom0
>
> |./xen-mfndump dump-p2m 0
Hi Julien,
> On 16 Apr 2021, at 3:35 pm, Julien Grall wrote:
>
> Hi,
>
> On 16/04/2021 12:25, Rahul Singh wrote:
>> Revert the code that associates the group pointer with the S2CR as this
>> code causing an issue when the SMMU device has more than one master
>> device.
>
> It is not clear to
Hello Guys,
Does memory on Dom0 also mapped to gpfn or it is mapped directly to mfn?
If mapped to gpfn, how can I access its p2m mapping?
I'm trying to use the xen-mfndump but it is not working with dom0
./xen-mfndump dump-p2m 0
xc: error: Could not map the shared info frame (MFN 0xddfe9) (3
Hi,
On 16/04/2021 12:25, Rahul Singh wrote:
Revert the code that associates the group pointer with the S2CR as this
code causing an issue when the SMMU device has more than one master
device.
It is not clear to me why this change was first added. Are we missing
any feature when reverting it?
Hi Rahul,
> On 16 Apr 2021, at 12:25, Rahul Singh wrote:
>
> Revert the code that associates the group pointer with the S2CR as this
> code causing an issue when the SMMU device has more than one master
> device.
>
> This code is merged with the commit "xen/arm: smmuv1: Intelligent
> SMR
On 16.04.2021 16:21, Andrew Cooper wrote:
> On 16/04/2021 14:20, Jan Beulich wrote:
>> For Intel CPUs we record L3 cache size, hence we should also do so for
>> AMD and alike.
>>
>> While making these additions, also make sure (throughout the function)
>> that we don't needlessly overwrite prior
On 16.04.2021 15:41, Andrew Cooper wrote:
> On 16/04/2021 09:16, Jan Beulich wrote:
>> clang, at the very least, doesn't like unused inline functions, unless
>> their definitions live in a header.
>>
>> Fixes: d23d792478 ("x86: avoid building COMPAT code when !HVM && !PV32")
>> Reported-by: Andrew
On 16/04/2021 14:20, Jan Beulich wrote:
> For Intel CPUs we record L3 cache size, hence we should also do so for
> AMD and alike.
>
> While making these additions, also make sure (throughout the function)
> that we don't needlessly overwrite prior values when the new value to be
> stored is zero.
On 15/04/2021 15:04, Jan Beulich wrote:
> On 15.04.2021 15:21, Andrew Cooper wrote:
>> The type is no longer appropriate for anything other than PV, and therefore
>> should not retain its generic name.
>>
>> Fixes: 527922008bc ("x86: slim down hypercall handling when !PV32")
>> Signed-off-by:
On 16/04/2021 09:16, Jan Beulich wrote:
> clang, at the very least, doesn't like unused inline functions, unless
> their definitions live in a header.
>
> Fixes: d23d792478 ("x86: avoid building COMPAT code when !HVM && !PV32")
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
I agree
On 16/04/2021 14:22, Jan Beulich wrote:
> Like ERMS this can always be exposed to guests, but I guess once we
> introduce full validation we want to make sure we don't reject incoming
> policies with any of these set when in the raw/host policies they're
> clear.
>
> Signed-off-by: Jan Beulich
Like ERMS this can always be exposed to guests, but I guess once we
introduce full validation we want to make sure we don't reject incoming
policies with any of these set when in the raw/host policies they're
clear.
Signed-off-by: Jan Beulich
--- a/tools/libs/light/libxl_cpuid.c
+++
For Intel CPUs we record L3 cache size, hence we should also do so for
AMD and alike.
While making these additions, also make sure (throughout the function)
that we don't needlessly overwrite prior values when the new value to be
stored is zero.
Signed-off-by: Jan Beulich
---
I have to admit
Zapping leaf data for out of range leaves is just one half of it: To
avoid guests (bogusly or worse) inferring information from mere leaf
presence, also shrink maximum indicators such that the respective
trailing entry is not all blank (unless of course it's the initial
subleaf of a leaf that's
On 16.04.2021 14:39, Andrew Cooper wrote:
> On 16/04/2021 13:32, Jan Beulich wrote:
>> With the building of guest_?.o now depending on PV or HVM, without
>> further #ifdef-ary shadow code won't link anymore when !PV && !HVM.
>> Since this isn't a useful configuration anyway, exclude shadow code
On 16/04/2021 13:32, Jan Beulich wrote:
> With the building of guest_?.o now depending on PV or HVM, without
> further #ifdef-ary shadow code won't link anymore when !PV && !HVM.
> Since this isn't a useful configuration anyway, exclude shadow code from
> being built in this case.
>
> Fixes:
With the building of guest_?.o now depending on PV or HVM, without
further #ifdef-ary shadow code won't link anymore when !PV && !HVM.
Since this isn't a useful configuration anyway, exclude shadow code from
being built in this case.
Fixes: aff8bf94ce65 ("x86/shadow: only 4-level guest code needs
flight 161187 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161187/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 96479947bcd7b425e4f2196b06701fd8ec3da595
baseline version:
ovmf
flight 161185 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161185/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
On 16.04.2021 13:46, Andrew Cooper wrote:
> dom0_update_physmap() is mostly called in two tight loops, where the lfences
> hidden in is_pv_32bit_domain() have a substantial impact.
>
> None of the boot time construction needs protection against malicious
> speculation, so use a local variable and
dom0_update_physmap() is mostly called in two tight loops, where the lfences
hidden in is_pv_32bit_domain() have a substantial impact.
None of the boot time construction needs protection against malicious
speculation, so use a local variable and calculate is_pv_32bit_domain() just
once.
Reformat
Revert the code that associates the group pointer with the S2CR as this
code causing an issue when the SMMU device has more than one master
device.
This code is merged with the commit "xen/arm: smmuv1: Intelligent
SMR allocation”.
Signed-off-by: Rahul Singh
---
flight 161180 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161180/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161153
test-amd64-amd64-qemuu-nested-amd
clang, at the very least, doesn't like unused inline functions, unless
their definitions live in a header.
Fixes: d23d792478 ("x86: avoid building COMPAT code when !HVM && !PV32")
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/oprofile/backtrace.c
+++
flight 161192 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161192/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 15.04.2021 18:10, Tim Deegan wrote:
> At 13:46 +0200 on 12 Apr (1618235218), Jan Beulich wrote:
>> The aspect of the function the second patch here changes has been
>> puzzling me for many years. I finally thought I ought to make an
>> attempt at reducing this to just a single
On 15.04.2021 18:04, Roger Pau Monné wrote:
> On Wed, Apr 07, 2021 at 07:08:06PM +0200, Roger Pau Monné wrote:
>> On Wed, Apr 07, 2021 at 05:51:14PM +0200, Jan Beulich wrote:
>>> On 31.03.2021 12:32, Roger Pau Monne wrote:
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
flight 161175 xen-4.12-testing real [real]
flight 161194 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161175/
http://logs.test-lab.xenproject.org/osstest/logs/161194/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
43 matches
Mail list logo
