flight 162247 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162247/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 162175
test-amd64-i386-xl-qemut-win7-amd64 19
flight 162246 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162246/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR.
vs. 152332
test-amd
On Wed, May 26, 2021 at 02:29:53PM -0400, Boris Ostrovsky wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On 5/26/21 12:40 AM, Anchal Agarwal wrote:
> >
Force WB type for grants and foreign pages. Those are usually mapped
over unpopulated physical ranges in the p2m, and those ranges would
usually be UC in the MTRR state, which is unlikely to be the correct
cache attribute. It's also cumbersome (or even impossible) for the
guest to be setting the MT
This is an EPT specific function, so it shouldn't live in the generic
mtrr file. Such movement is also needed for future work that will
require passing a p2m_type_t parameter to epte_get_entry_emt, and
making that type visible to the mtrr users is cumbersome and
unneeded.
Moving epte_get_entry_emt
Fixes: 1c84d04673 ('VMX: remove the problematic set_uc_mode logic')
Signed-off-by: Roger Pau Monné
---
xen/include/asm-x86/mtrr.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/include/asm-x86/mtrr.h b/xen/include/asm-x86/mtrr.h
index 4be704cb6a..24e5de5c22 100644
--- a/xen/include/asm-
Hello,
The aim of this series is to force the cache attribute of foreign and
grant mappings to WB for HVM/PVH guests. This is required because those
mappings will be likely be using unpopulated memory ranges in the p2m,
and those are usually UC in the MTRR state.
Having the guest set the correc
Julien Grall writes:
> On 28/05/2021 13:49, Alex Bennée wrote:
>> Hi,
>
> Hi Alex,
>
>> I'm currently trying to pull together the threads for booting Xen on
>> Debian. I'm currently doing this within QEMU's TCG emulation and the
>> "virt" machine model:
>>-machine type=virt,virtualization=o
flight 162244 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162244/
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
test-amd64-am
Hi,
At 10:58 +0200 on 25 May (1621940330), Jan Beulich wrote:
> On 24.05.2021 06:29, Roberto Bagnara wrote:
> > I stumbled upon parsing errors due to invalid uses of
> > _Static_assert expanded from HASH_CALLBACKS_CHECK where
> > the tested expression is not constant, as mandated by
> > the C stan
On 28/05/2021 13:49, Alex Bennée wrote:
Hi,
Hi Alex,
I'm currently trying to pull together the threads for booting Xen on
Debian. I'm currently doing this within QEMU's TCG emulation and the
"virt" machine model:
-machine type=virt,virtualization=on,gic-version=3 \
-cpu max,pauth-i
On Tue, 2021-04-27 at 10:35 +0200, Jan Beulich wrote:
> On 19.03.2021 13:14, Dario Faggioli wrote:
> >
> > ---
> > Cc: George Dunlap
> > Cc: Ian Jackson
> > ---
> > Despite the limited effect, it's a bug. So:
> > - it should be backported;
> > - I think it should be included in 4.15. The risk is
A !runnable unit (temporarily) present in the runq may cause us to
stop scanning the runq itself too early. Of course, we don't run any
non-runnable vCPUs, but we end the scan and we fallback to picking
the idle unit. In other word, this prevent us to find there and pick
the actual unit that we're
Hi,
I'm currently trying to pull together the threads for booting Xen on
Debian. I'm currently doing this within QEMU's TCG emulation and the
"virt" machine model:
-machine type=virt,virtualization=on,gic-version=3 \
-cpu max,pauth-impdef=on
with the firmware on my Ubuntu machine:
-driv
Hi Roger,
On 28/05/2021 14:31, Roger Pau Monné wrote:
On Fri, May 28, 2021 at 11:48:51AM +0100, Julien Grall wrote:
Hi Jan,
On 28/05/2021 11:23, Jan Beulich wrote:
On 28.05.2021 10:30, Roger Pau Monné wrote:
On Thu, May 27, 2021 at 07:48:41PM +0100, Julien Grall wrote:
On 27/05/2021 12:28,
flight 162242 xen-unstable real [real]
flight 162248 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162242/
http://logs.test-lab.xenproject.org/osstest/logs/162248/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 28.05.2021 15:31, Roger Pau Monné wrote:
> I think I'm being extremely dull here, sorry. From your text I
> understand that the value returned by is_port_valid could be stale by
> the time the user reads it?
>
> I think there's some condition that makes this value stale, and it's
> not the comm
On 28.05.2021 15:19, Jason Andryuk wrote:
> On Thu, May 27, 2021 at 4:03 AM Jan Beulich wrote:
>> On 03.05.2021 21:28, Jason Andryuk wrote:
>>> --- a/xen/drivers/acpi/pmstat.c
>>> +++ b/xen/drivers/acpi/pmstat.c
>>> @@ -290,6 +290,12 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op
>>> *op)
On Fri, May 28, 2021 at 11:48:51AM +0100, Julien Grall wrote:
> Hi Jan,
>
> On 28/05/2021 11:23, Jan Beulich wrote:
> > On 28.05.2021 10:30, Roger Pau Monné wrote:
> > > On Thu, May 27, 2021 at 07:48:41PM +0100, Julien Grall wrote:
> > > > On 27/05/2021 12:28, Jan Beulich wrote:
> > > > > port_is_
On 26.05.2021 17:21, Julien Grall wrote:
> From: Julien Grall
>
> Since XSA-288 (commit 02cbeeb62075 "gnttab: split maptrack lock to make
XSA-228 I suppose?
> it fulfill its purpose again"), v->maptrack_head and v->maptrack_tail
> are with the lock v->maptrack_freelist_lock held.
Nit: missing
On Thu, May 27, 2021 at 4:03 AM Jan Beulich wrote:
>
> On 03.05.2021 21:28, Jason Andryuk wrote:
> > --- a/xen/drivers/acpi/pmstat.c
> > +++ b/xen/drivers/acpi/pmstat.c
> > @@ -290,6 +290,12 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op
> > *op)
> > &op->u.get_para.u.ondeman
Hi Jan,
On 28/05/2021 11:23, Jan Beulich wrote:
On 28.05.2021 10:30, Roger Pau Monné wrote:
On Thu, May 27, 2021 at 07:48:41PM +0100, Julien Grall wrote:
On 27/05/2021 12:28, Jan Beulich wrote:
port_is_valid() and evtchn_from_port() are fine to use without holding
any locks. Accordingly acqui
On 28.05.2021 10:30, Roger Pau Monné wrote:
> On Thu, May 27, 2021 at 07:48:41PM +0100, Julien Grall wrote:
>> On 27/05/2021 12:28, Jan Beulich wrote:
>>> port_is_valid() and evtchn_from_port() are fine to use without holding
>>> any locks. Accordingly acquire the per-domain lock slightly later in
flight 162245 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162245/
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 1
On 28.05.2021 11:59, Roberto Bagnara wrote:
> On 25/05/21 10:58, Jan Beulich wrote:
>> On 24.05.2021 06:29, Roberto Bagnara wrote:
>>> I stumbled upon parsing errors due to invalid uses of
>>> _Static_assert expanded from HASH_CALLBACKS_CHECK where
>>> the tested expression is not constant, as mand
flight 162241 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162241/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs.
152332
test-amd64-i3
Hi Jan.
Please see below.
On 25/05/21 10:58, Jan Beulich wrote:
On 24.05.2021 06:29, Roberto Bagnara wrote:
I stumbled upon parsing errors due to invalid uses of
_Static_assert expanded from HASH_CALLBACKS_CHECK where
the tested expression is not constant, as mandated by
the C standard.
Judgi
On Thu, May 27, 2021 at 07:48:41PM +0100, Julien Grall wrote:
> Hi Jan,
>
> On 27/05/2021 12:28, Jan Beulich wrote:
> > port_is_valid() and evtchn_from_port() are fine to use without holding
> > any locks. Accordingly acquire the per-domain lock slightly later in
> > evtchn_close() and evtchn_bind
On 25.05.2021 09:06, Jan Beulich wrote:
> On 25.05.2021 09:02, Jan Beulich wrote:
>> On 24.05.2021 16:34, Connor Davis wrote:
>>> Defaulting to yes only for X86 and ARM reduces the requirements
>>> for a minimal build when porting new architectures.
>>>
>>> Signed-off-by: Connor Davis
>>> Reviewed
On 25.05.2021 10:44, Jan Beulich wrote:
> On 24.05.2021 16:34, Connor Davis wrote:
>> --- a/xen/include/xen/iommu.h
>> +++ b/xen/include/xen/iommu.h
>> @@ -51,9 +51,15 @@ static inline bool_t dfn_eq(dfn_t x, dfn_t y)
>> return dfn_x(x) == dfn_x(y);
>> }
>>
>> -extern bool_t iommu_enable, io
On 21.05.2021 15:31, Jan Beulich wrote:
> On 20.05.2021 14:35, Jan Beulich wrote:
>> On 20.05.2021 14:30, Roger Pau Monne wrote:
>>> The legacy __xen_guest section doesn't support the PHYS32_ENTRY
>>> elfnote, so it's pointless to attempt to parse the elfnotes from that
>>> section when called from
On 19.05.2021 17:49, Jan Beulich wrote:
> Replace a bogus cast, move the static variable into the only function
> using it, and add __initconst. While there, also remove a pointless NULL
> check.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/tboot.c
> +++ b/xen/arch/x86/tboot.c
> @@ -27,
On 19.05.2021 17:48, Jan Beulich wrote:
> The difference of two pdx_to_page() return values is a number of pages,
> not the number of bytes covered by the corresponding frame table entries.
>
> Fixes: 3cb68d2b59ab ("tboot: fix S3 issue for Intel Trusted Execution
> Technology.")
> Signed-off-by:
33 matches
Mail list logo
