flight 175453 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175453/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail in
175440 pass in 175453
flight 175451 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175451/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 8 xen-boot fail REGR. vs. 173462
Hi Vipul,
Great that you managed to setup a debugging environment. The logs look
very promising: it looks like xenfb.c is handling events as expected.
So it would apparently seem that xen-fbfront.c -> xenfb.c connection is
working.
So the next step is the xenfb.c -> ./ui/vnc.c is working.
It
On Sat, 17 Dec 2022, Julien Grall wrote:
> On 17/12/2022 00:46, Stefano Stabellini wrote:
> > On Fri, 16 Dec 2022, Julien Grall wrote:
> > > Hi Ayan,
> > >
> > > On 15/12/2022 19:32, Ayan Kumar Halder wrote:
> > > > paddr_t may be u64 or u32 depending of the type of architecture.
> > > > Thus,
On Tue, 20 Dec 2022, Oleksii Moisieiev wrote:
> Data buffer for active map is allocated in alloc_active_ring and freed
> in free_active_ring function, which is used only for the error
> cleanup. pvcalls_front_release is calling pvcalls_front_free_map which
> ends foreign access for this buffer,
No functional change intended.
Signed-off-by: Demi Marie Obenour
---
Changes since v2:
- Keep MTRR_NUM_TYPES and adjust commit message accordingly
---
xen/arch/x86/hvm/mtrr.c | 18 +-
xen/arch/x86/include/asm/mtrr.h | 2 --
xen/arch/x86/mm/shadow/multi.c | 2 +-
3
Setting cacheability flags that are not ones specified by Xen is a bug
in the guest. By default, return -EINVAL if a guests attempts to do
this. The invalid-cacheability= Xen command-line flag allows the
administrator to allow such attempts or to produce
Suggested-by: Andrew Cooper
It may be desirable to change Xen's PAT for various reasons. This
requires changes to several _PAGE_* macros as well. Add static
assertions to check that XEN_MSR_PAT is consistent with the _PAGE_*
macros, and that _PAGE_WB is 0 as required by Linux.
Signed-off-by: Demi Marie Obenour
---
This is purely for testing, to see if it works around a bug in i915. It
is not intended to be merged.
NOT-signed-off-by: DO NOT MERGE
---
xen/arch/x86/include/asm/page.h | 4 ++--
xen/arch/x86/include/asm/processor.h | 10 +-
xen/arch/x86/mm.c| 8
3
get_page_from_l1e() relied on Xen's choice of PAT, which is brittle in
the face of future PAT changes. Instead, compute the actual cacheability
used by the CPU and switch on that, as this will work no matter what PAT
Xen uses.
No functional change intended. This code is itself questionable and
While working on Qubes OS Marek found out that there were some PAT hacks
in the Linux i195 driver. I decided to make Xen use Linux’s PAT to see
if it solved the graphics glitches that were observed; it did. This
required a substantial amount of preliminary work that is useful even
without using
flight 175461 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175461/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d8d4abdff9096a69ff59d96ac4a8dd0e19e5cbcc
baseline version:
ovmf
On Thu, 22 Dec 2022, Jan Beulich wrote:
> On 22.12.2022 03:01, Stefano Stabellini wrote:
> > What do you guys think? Nice automatic 20.7 scans for all patches and
> > for staging, but with the undesirable false-positive comments, or
> > no-20.7 scans but no comments in the tree?
>
> Anything
On Thu, 22 Dec 2022, Julien Grall wrote:
> > What other hypervisors might or might not do should not be a factor in
> > this discussion and it would be best to leave it aside.
>
> To be honest, Demi has a point. At the moment, VMF is a very niche use-case
> (see more below). So you would end up
flight 175450 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175450/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175436
test-armhf-armhf-libvirt-raw 15
flight 175447 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175447/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 175096
flight 175458 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175458/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 538ac013d6a673842d780c88b7b3c21730260e8e
baseline version:
ovmf
flight 175446 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175446/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-migrupgrade broken in 175434
Hi Jan
On Wed, Dec 7, 2022 at 12:52 PM Jan Beulich wrote:
>
> On 22.10.2022 18:08, Carlo Nonato wrote:
> > This commit replaces the colored allocator for domains with a simple buddy
> > allocator indexed also by colors, so that it can allocate pages based on
> > some coloring configuration.
> >
Hi Anthony,
On Thu, Nov 24, 2022 at 4:21 PM Anthony PERARD
wrote:
>
> On Sat, Oct 22, 2022 at 05:51:15PM +0200, Carlo Nonato wrote:
> > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > index b2901e04cf..5f53cec8bf 100644
> > --- a/docs/man/xl.cfg.5.pod.in
> > +++
flight 175445 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175445/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 broken in 175407
On 16.12.2022 12:48, Julien Grall wrote:
> From: Julien Grall
>
> At the moment the fixmap slots are prefixed differently between arm and
> x86.
>
> Some of them (e.g. the PMAP slots) are used in common code. So it would
> be better if they are named the same way to avoid having to create
>
On 16.12.2022 12:48, Julien Grall wrote:
> From: Hongyan Xia
>
> Also add a helper function to retrieve it. Change arch_mfns_in_direct_map
> to check this option before returning.
I think the abstract parts of this want to be generic right away. I can't
see why Arm would not suffer from the
On 16.12.2022 12:48, Julien Grall wrote:
> From: Hongyan Xia
>
> In order to use the mapcache in the idle domain, we also have to
> populate its page tables in the PERDOMAIN region, and we need to move
> mapcache_domain_init() earlier in arch_domain_create().
>
> Note, commit 'x86: lift
On 16.12.2022 12:48, Julien Grall wrote:
> From: Wei Liu
>
> It is going to be needed by HVM and idle domain as well, because without
> the direct map, both need a mapcache to map pages.
>
> This only lifts the mapcache variable up. Whether we populate the
> mapcache for a domain is unchanged
flight 175455 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175455/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
On 16.12.2022 12:48, Julien Grall wrote:
> From: Hongyan Xia
>
> Building a PV dom0 is allocating from the domheap but uses it like the
> xenheap. This is clearly wrong. Fix.
"Clearly wrong" would mean there's a bug here, at lest under certain
conditions. But there isn't: Even on huge systems,
flight 175443 qemu-mainline real [real]
flight 175456 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175443/
http://logs.test-lab.xenproject.org/osstest/logs/175456/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 16.12.2022 12:48, Julien Grall wrote:
> From: Wei Liu
>
> Xen shouldn't use domheap page as if they were xenheap pages. Map and
> unmap pages accordingly.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Wei Wang
> Signed-off-by: Julien Grall
>
>
>
> Changes since Hongyan's version:
On 16.12.2022 12:48, Julien Grall wrote:
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -165,7 +165,24 @@ restore_all_guest:
> and %rsi, %rdi
> and %r9, %rsi
> add %rcx, %rdi
> -add %rcx, %rsi
> +
> + /*
> +
On Thu, Dec 22, 2022 at 10:21:57AM +, Julien Grall wrote:
>
>
> On 22/12/2022 10:14, Demi Marie Obenour wrote:
> > On Thu, Dec 22, 2022 at 09:52:11AM +, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 22/12/2022 00:38, Stefano Stabellini wrote:
> > > > On Tue, 20 Dec 2022, Smith,
On 22/12/2022 10:14, Demi Marie Obenour wrote:
On Thu, Dec 22, 2022 at 09:52:11AM +, Julien Grall wrote:
Hi Stefano,
On 22/12/2022 00:38, Stefano Stabellini wrote:
On Tue, 20 Dec 2022, Smith, Jackson wrote:
Hi Stefano,
On 16/12/2022 01:46, Stefano Stabellini wrote:
On Thu, 15 Dec
On Thu, Dec 22, 2022 at 09:52:11AM +, Julien Grall wrote:
> Hi Stefano,
>
> On 22/12/2022 00:38, Stefano Stabellini wrote:
> > On Tue, 20 Dec 2022, Smith, Jackson wrote:
> > > > Hi Stefano,
> > > >
> > > > On 16/12/2022 01:46, Stefano Stabellini wrote:
> > > > > On Thu, 15 Dec 2022, Julien
On 22.12.2022 10:55, Demi Marie Obenour wrote:
> On Thu, Dec 22, 2022 at 10:48:02AM +0100, Jan Beulich wrote:
>> Also wasn't there talk of having this behavior in debug hypervisors
>> only? Without that restriction I'm yet less happy with the change ...
>
> My understanding was that Andrew
On 22.12.2022 11:00, Demi Marie Obenour wrote:
> On Thu, Dec 22, 2022 at 10:54:48AM +0100, Jan Beulich wrote:
>> On 22.12.2022 10:50, Demi Marie Obenour wrote:
>>> On Thu, Dec 22, 2022 at 10:35:08AM +0100, Jan Beulich wrote:
On 20.12.2022 02:07, Demi Marie Obenour wrote:
> @@ -6361,6
On Thu, Dec 22, 2022 at 10:54:48AM +0100, Jan Beulich wrote:
> On 22.12.2022 10:50, Demi Marie Obenour wrote:
> > On Thu, Dec 22, 2022 at 10:35:08AM +0100, Jan Beulich wrote:
> >> On 20.12.2022 02:07, Demi Marie Obenour wrote:
> >>> --- a/xen/arch/x86/mm.c
> >>> +++ b/xen/arch/x86/mm.c
> >>> @@
On Thu, Dec 22, 2022 at 10:51:08AM +0100, Jan Beulich wrote:
> On 20.12.2022 09:19, Jan Beulich wrote:
> > On 20.12.2022 02:07, Demi Marie Obenour wrote:
> >> get_page_from_l1e() relied on Xen's choice of PAT, which is brittle in
> >> the face of future PAT changes. Instead, compute the actual
On Thu, Dec 22, 2022 at 10:48:02AM +0100, Jan Beulich wrote:
> On 20.12.2022 02:07, Demi Marie Obenour wrote:
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -145,6 +145,8 @@
> >
> > #ifdef CONFIG_PV
> > #include "pv/mm.h"
> > +bool allow_invalid_cacheability;
>
> static and
On 22.12.2022 10:50, Demi Marie Obenour wrote:
> On Thu, Dec 22, 2022 at 10:35:08AM +0100, Jan Beulich wrote:
>> On 20.12.2022 02:07, Demi Marie Obenour wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -6352,6 +6352,11 @@ unsigned long get_upper_mfn_bound(void)
>>> return
Hi Stefano,
On 22/12/2022 00:38, Stefano Stabellini wrote:
On Tue, 20 Dec 2022, Smith, Jackson wrote:
Hi Stefano,
On 16/12/2022 01:46, Stefano Stabellini wrote:
On Thu, 15 Dec 2022, Julien Grall wrote:
On 13/12/2022 19:48, Smith, Jackson wrote:
Yes, we are familiar with the "secret-free
On 20.12.2022 09:19, Jan Beulich wrote:
> On 20.12.2022 02:07, Demi Marie Obenour wrote:
>> get_page_from_l1e() relied on Xen's choice of PAT, which is brittle in
>> the face of future PAT changes. Instead, compute the actual cacheability
>> used by the CPU and switch on that, as this will work
On Thu, Dec 22, 2022 at 10:35:08AM +0100, Jan Beulich wrote:
> On 20.12.2022 02:07, Demi Marie Obenour wrote:
> > It may be desirable to change Xen's PAT for various reasons. This
> > requires changes to several _PAGE_* macros as well. Add static
> > assertions to check that XEN_MSR_PAT is
On 20.12.2022 02:07, Demi Marie Obenour wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -145,6 +145,8 @@
>
> #ifdef CONFIG_PV
> #include "pv/mm.h"
> +bool allow_invalid_cacheability;
static and __ro_after_init please (the former not the least with Misra
in mind).
>
flight 175442 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175442/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-i386-xsm broken
On 20.12.2022 02:07, Demi Marie Obenour wrote:
> It may be desirable to change Xen's PAT for various reasons. This
> requires changes to several _PAGE_* macros as well. Add static
> assertions to check that XEN_MSR_PAT is consistent with the _PAGE_*
> macros, and that _PAGE_WB is 0 as required
Hi Stefano,
On 22/12/2022 00:53, Stefano Stabellini wrote:
On Tue, 20 Dec 2022, Demi Marie Obenour wrote:
On Tue, Dec 20, 2022 at 10:17:24PM +, Smith, Jackson wrote:
Hi Stefano,
On 16/12/2022 01:46, Stefano Stabellini wrote:
On Thu, 15 Dec 2022, Julien Grall wrote:
On 13/12/2022 19:48,
flight 175452 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175452/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ec87305f90d90096aac2a4d91e3f6556e2ecd6b9
baseline version:
ovmf
On 22.12.2022 03:01, Stefano Stabellini wrote:
> What do you guys think? Nice automatic 20.7 scans for all patches and
> for staging, but with the undesirable false-positive comments, or
> no-20.7 scans but no comments in the tree?
Anything automatic which then also bugs submitters about issues
Queued, thanks.
Paolo
On Fri, Dec 16, 2022 at 03:30:13PM +, Andrew Cooper wrote:
> On 08/12/2022 1:55 pm, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > There is an issue with i915 on Xen PV (dom0). The end result is a lot of
> > glitches, like here: https://openqa.qubes-os.org/tests/54748#step/startup/8
> >
On 21.12.2022 19:58, Andrew Cooper wrote:
> On 21/12/2022 1:27 pm, Jan Beulich wrote:
>> Drop the SH_type_none entry - there are no allocation attempts with
>> this type, and there also shouldn't be any. Adjust the shadow_size()
>> alternative path to match that change. Also generalize two related
On 21.12.2022 18:43, Andrew Cooper wrote:
> On 21/12/2022 1:25 pm, Jan Beulich wrote:
>> The hook isn't mode dependent, hence it's misplaced in struct
>> paging_mode. (Or alternatively I see no reason why the alloc_page() and
>> free_page() hooks don't also live there.) Move it to struct
>>
52 matches
Mail list logo
