flight 152329 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152329/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9001b750df64b25b14ec45a2efa1361a7b96c00a
baseline version:
ovmf 7f79b736b0a57da71d87c
flight 152324 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152324/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 151065
test-amd64-i386-x
flight 152334 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152334/
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 Fri, 31 Jul 2020, Bertrand Marquis wrote:
> Sorry missed some points in my previous answer.
>
> > On 30 Jul 2020, at 22:50, Julien Grall wrote:
> >
> > Hi Bertrand,
> >
> > To avoid extra work on your side, I would recommend to wait a bit before
> > sending a new version. It would be good t
On Fri, 31 Jul 2020, Bertrand Marquis wrote:
> > On 31 Jul 2020, at 12:18, Jan Beulich wrote:
> >
> > On 31.07.2020 12:12, Julien Grall wrote:
> >> On 31/07/2020 07:39, Jan Beulich wrote:
> >>> We're fixing other issues without breaking the ABI. Where's the
> >>> problem of backporting the kernel
flight 152313 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152313/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 152287
test-amd64-amd64-am
flight 152327 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152327/
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
> -Original Message-
> From: Paul Durrant
> Sent: 31 July 2020 15:26
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
>
> Subject: [EXTERNAL] [PATCH v3 1/2] x86/hvm: set 'ipat' in EPT for special
> pages
>
> CAUTION
> -Original Message-
> From: Jan Beulich
> Sent: 31 July 2020 14:41
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> 'Andrew Cooper'
> ; 'Wei Liu' ; 'Roger Pau Monné'
>
> Subject: RE: [EXTERNAL] [PATCH v2 2/2] x86/hvm: simplify 'mmio_direct' check
> in epte_ge
On Fri, 31 Jul 2020, George Dunlap wrote:
> > On Jul 31, 2020, at 12:29 PM, Jan Beulich wrote:
> >
> > On 30.07.2020 03:27, Stefano Stabellini wrote:
> >> Hi all,
> >>
> >> I would like to ask for your feedback on the adoption of the kernel-doc
> >> format for in-code comments.
> >>
> >> In the
On 31/07/2020 15:54, Jan Beulich wrote:
> On 14.07.2020 10:06, Jan Beulich wrote:
>> gcc re-orders top level blocks by default when optimizing. This
>> re-ordering results in all our .type directives to get emitted to the
>> assembly file first, followed by gcc's. The assembler warns about
>> attem
This is in order that we can substantially simplify forthcoming
database changes. If mercurial support were still desired, the right
thing to do would be to rework it now along the lines of this request.
But we haven't used it for some years.
It could be reenabled later, if this work were done th
George Dunlap writes ("Re: [OSSTEST PATCH v2 08/41] sg-report-flight: Ask the
db for flights of interest"):
> > On Jul 31, 2020, at 12:37 PM, Ian Jackson wrote:
> > Specifically, we narrow the initial query to flights which have at
> > least some job with the built_revision_foo we are looking for
On 31/07/2020 15:58, Jan Beulich wrote:
> On 15.07.2020 11:59, Jan Beulich wrote:
>> The filling and cleaning up of v->arch.guest_table in new_guest_cr3()
>> was apparently inconsistent so far: There was a type ref acquired
>> unconditionally for the new top level page table, but the dropping of
>>
flight 152315 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152315/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7f79b736b0a57da71d87c987357db0227cd16ac6
baseline version:
ovmf e848b58d7c85293cd4121
Hi Bertrand,
On 31/07/2020 14:09, Bertrand Marquis wrote:
On 31 Jul 2020, at 14:19, Jan Beulich wrote:
On 30.07.2020 22:50, Julien Grall wrote:
On 30/07/2020 11:24, Bertrand Marquis wrote:
At the moment on Arm, a Linux guest running with KTPI enabled will
cause the following error when a
On 15.07.2020 11:59, Jan Beulich wrote:
> The filling and cleaning up of v->arch.guest_table in new_guest_cr3()
> was apparently inconsistent so far: There was a type ref acquired
> unconditionally for the new top level page table, but the dropping of
> the old type ref was conditional upon !paging
George Dunlap writes ("Re: [OSSTEST PATCH v2 07/41] schema: Provide indices for
sg-report-flight"):
>
>
> > On Jul 31, 2020, at 12:37 PM, Ian Jackson wrote:
> >
> > These indexes allow very fast lookup of "relevant" flights eg when
> > trying to justify failures.
> >
> > In my ad-hoc test cas
On 15.07.2020 09:45, Jan Beulich wrote:
> Except for hvm_shadow_max_featuremask and deep_features they're
> referenced by __init functions only.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -16,12 +16,15 @@
> const uint32_t known_features[] = I
On 31/07/2020 15:44, Jan Beulich wrote:
> On 28.07.2020 13:37, Andrew Cooper wrote:
>> @@ -1026,19 +1047,6 @@ static int acquire_resource(
>> if ( xmar.pad != 0 )
>> return -EINVAL;
>>
>> -if ( guest_handle_is_null(xmar.frame_list) )
>> -{
>> -if ( xmar.nr_frames )
>
On 14.07.2020 10:06, Jan Beulich wrote:
> gcc re-orders top level blocks by default when optimizing. This
> re-ordering results in all our .type directives to get emitted to the
> assembly file first, followed by gcc's. The assembler warns about
> attempts to change the type of a symbol when it was
On 31.07.2020 16:41, Paul Durrant wrote:
> From: Paul Durrant
>
> Paul Durrant (2):
> x86/hvm: set 'ipat' in EPT for special pages
> x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()
Reviewed-by: Jan Beulich
On 28.07.2020 13:37, Andrew Cooper wrote:
> @@ -1026,19 +1047,6 @@ static int acquire_resource(
> if ( xmar.pad != 0 )
> return -EINVAL;
>
> -if ( guest_handle_is_null(xmar.frame_list) )
> -{
> -if ( xmar.nr_frames )
> -return -EINVAL;
> -
> -xmar
From: Paul Durrant
Paul Durrant (2):
x86/hvm: set 'ipat' in EPT for special pages
x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()
xen/arch/x86/hvm/mtrr.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
--
2.20.1
From: Paul Durrant
Re-factor the code to take advantage of the fact that the APIC access page is
a 'special' page. The VMX code is left alone and hence the APIC access page is
still inserted into the P2M with type p2m_mmio_direct. This is left alone as it
is not obvious there is another suitable
From: Paul Durrant
All non-MMIO ranges (i.e those not mapping real device MMIO regions) that
map valid MFNs are normally marked MTRR_TYPE_WRBACK and 'ipat' is set. Hence
when PV drivers running in a guest populate the BAR space of the Xen Platform
PCI Device with pages such as the Shared Info pag
> On 31 Jul 2020, at 12:18, Jan Beulich wrote:
>
> On 31.07.2020 12:12, Julien Grall wrote:
>> On 31/07/2020 07:39, Jan Beulich wrote:
>>> We're fixing other issues without breaking the ABI. Where's the
>>> problem of backporting the kernel side change (which I anticipate
>>> to not be overly
On 30.07.2020 21:46, Andrew Cooper wrote:
> On 30/07/2020 09:31, Paul Durrant wrote:
>>> From: Xen-devel On Behalf Of
>>> Andrew Cooper
>>> Sent: 28 July 2020 12:37
>>>
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -4013,6 +4013,25 @@ static int gnttab_get_shared_fr
From: Paul Durrant
Re-factor the code to take advantage of the fact that the APIC access page is
a 'special' page. The VMX code is left alone and hence the APIC access page is
still inserted into the P2M with type p2m_mmio_direct. This is left alone as it
is not obvious there is another suitable
From: Paul Durrant
Paul Durrant (2):
x86/hvm: set 'ipat' in EPT for special pages
x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()
xen/arch/x86/hvm/mtrr.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
---
Cc: Andrew Cooper
Cc: Jan Beulich
From: Paul Durrant
All non-MMIO ranges (i.e those not mapping real device MMIO regions) that
map valid MFNs are normally marked MTRR_TYPE_WRBACK and 'ipat' is set. Hence
when PV drivers running in a guest populate the BAR space of the Xen Platform
PCI Device with pages such as the Shared Info pag
On Fri, Jul 31, 2020 at 4:14 PM Boris Ostrovsky
wrote:
>
> On 7/30/20 7:06 PM, Anchal Agarwal wrote:
> > On Mon, Jul 27, 2020 at 06:08:29PM -0400, Boris Ostrovsky wrote:
> >> CAUTION: This email originated from outside of the organization. Do not
> >> click links or open attachments unless you ca
> On Jul 31, 2020, at 12:37 PM, Ian Jackson wrote:
>
> These indexes allow very fast lookup of "relevant" flights eg when
> trying to justify failures.
>
> In my ad-hoc test case, these indices (along with the subsequent
> changes to sg-report-flight and Executive.pm, reduce the runtime of
>
> On Jul 31, 2020, at 12:37 PM, Ian Jackson wrote:
>
> In "Executive: Use index for report__find_test" we changed an EXISTS
> subquery into a JOIN.
>
> Now, the condition r.flight=f.flight is redundant because this is the
> join column (from USING).
>
> No functional change.
>
> CC: George
> On Jul 31, 2020, at 12:37 PM, Ian Jackson wrote:
>
> Specifically, we narrow the initial query to flights which have at
> least some job with the built_revision_foo we are looking for.
>
> This condition is strictly broader than that implemented inside the
> flight search loop, so there is n
On 31.07.2020 15:43, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 31 July 2020 14:41
>> To: p...@xen.org
>> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ;
>> 'Andrew Cooper'
>> ; 'Wei Liu' ; 'Roger Pau Monné'
>>
>> Subject: Re: [PATCH v2 2/2] x86/hvm: si
On 7/30/20 7:06 PM, Anchal Agarwal wrote:
> On Mon, Jul 27, 2020 at 06:08:29PM -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 Jul 31, 2020, at 12:38 PM, Ian Jackson wrote:
>
> The condition on r.job is more naturally thought of as a join
> condition than a where condition. (This is an inner join, so the
> semantics are identical.)
>
> Also, for clarity, swap the flight and job conditions round, so that
> the O
> -Original Message-
> From: Paul Durrant
> Sent: 31 July 2020 14:44
> To: 'Jan Beulich'
> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ;
> 'Andrew Cooper'
> ; 'Wei Liu' ; 'Roger Pau Monné'
>
> Subject: RE: [PATCH v2 2/2] x86/hvm: simplify 'mmio_direct' check in
> epte_get_entry
On Fri, Jul 31, 2020 at 03:05:52PM +0200, Jan Beulich wrote:
> On 30.07.2020 16:03, Roger Pau Monne wrote:
> > Remove the unneeded else branch, which allows to reduce the
> > indentation of a larger block of code, while making the flow of the
> > function more obvious.
> >
> > No functional change
> On 31 Jul 2020, at 15:48, Andrew Cooper wrote:
>
> On 30/07/2020 02:27, Stefano Stabellini wrote:
>> Hi all,
>>
>> I would like to ask for your feedback on the adoption of the kernel-doc
>> format for in-code comments.
>>
>> In the FuSa SIG we have started looking into FuSa documents for Xe
> -Original Message-
> From: Jan Beulich
> Sent: 31 July 2020 14:41
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ;
> 'Andrew Cooper'
> ; 'Wei Liu' ; 'Roger Pau Monné'
>
> Subject: Re: [PATCH v2 2/2] x86/hvm: simplify 'mmio_direct' check in
> epte_get_entry_em
On 30/07/2020 02:27, Stefano Stabellini wrote:
> Hi all,
>
> I would like to ask for your feedback on the adoption of the kernel-doc
> format for in-code comments.
>
> In the FuSa SIG we have started looking into FuSa documents for Xen. One
> of the things we are investigating are ways to link thes
On 31.07.2020 15:46, Andrew Cooper wrote:
> On 31/07/2020 14:30, Jan Beulich wrote:
>> On 31.07.2020 15:02, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure
>>> variable"):
On 29.06.2020 14:05, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATC
On 31/07/2020 14:30, Jan Beulich wrote:
> On 31.07.2020 15:02, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure
>> variable"):
>>> On 29.06.2020 14:05, Ian Jackson wrote:
Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure
var
On 31.07.2020 15:07, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 31 July 2020 13:58
>> To: Paul Durrant
>> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
>> Andrew Cooper
>> ; Wei Liu ; Roger Pau Monné
>>
>> Subject: Re: [PATCH v2 2/2] x86/hvm: simplify
On 31.07.2020 15:02, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure
> variable"):
>> On 29.06.2020 14:05, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure
>>> variable"):
On 26.06.2020 19:00, Andrew Coope
Sorry missed some points in my previous answer.
> On 30 Jul 2020, at 22:50, Julien Grall wrote:
>
> Hi Bertrand,
>
> To avoid extra work on your side, I would recommend to wait a bit before
> sending a new version. It would be good to at least settle the conversation
> in v2 regarding the app
> -Original Message-
> From: Paul Durrant
> Sent: 30 July 2020 15:29
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George
> Dunlap ; Ian Jackson ;
> Julien Grall
> ; Stefano Stabellini ; Jun Nakajima
> ;
> Kev
> On 31 Jul 2020, at 03:18, Stefano Stabellini wrote:
>
> On Thu, 30 Jul 2020, Julien Grall wrote:
>> Hi Bertrand,
>>
>> To avoid extra work on your side, I would recommend to wait a bit before
>> sending a new version. It would be good to at least settle the conversation
>> in
>> v2 regardi
> On 30 Jul 2020, at 22:50, Julien Grall wrote:
>
> Hi Bertrand,
>
> To avoid extra work on your side, I would recommend to wait a bit before
> sending a new version. It would be good to at least settle the conversation
> in v2 regarding the approach taken.
Thanks for the advice.
I thought
> -Original Message-
> From: Jan Beulich
> Sent: 31 July 2020 13:58
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
>
> Subject: Re: [PATCH v2 2/2] x86/hvm: simplify 'mmio_direct' check in
> epte_get_entry_emt()
>
> On 31 Jul 2020, at 14:19, Jan Beulich wrote:
>
> On 30.07.2020 22:50, Julien Grall wrote:
>> On 30/07/2020 11:24, Bertrand Marquis wrote:
>>> At the moment on Arm, a Linux guest running with KTPI enabled will
>>> cause the following error when a context switch happens in user mode:
>>> (XEN)
On 30.07.2020 16:03, Roger Pau Monne wrote:
> Remove the unneeded else branch, which allows to reduce the
> indentation of a larger block of code, while making the flow of the
> function more obvious.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
> On 30 Jul 2020, at 20:18, Julien Grall wrote:
>
> From: Julien Grall
>
> Add emacs magics for xen/guest_access.h and
> asm-x86/guest_access.h.
>
> Signed-off-by: Julien Grall
> Acked-by: Jan Beulich
Most of file in Xen source code seem to have a white line before the “emacs
magics”.
If
Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure
variable"):
> On 29.06.2020 14:05, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure
> > variable"):
> >> On 26.06.2020 19:00, Andrew Cooper wrote:
> >> ... this may or may not take ef
On 31.07.2020 14:39, Paul Durrant wrote:
> From: Paul Durrant
>
> Re-factor the code to take advantage of the fact that the APIC access page is
> a 'special' page.
Hmm, that's going quite as far as I was thinking to go: In
particular, you leave in place the set_mmio_p2m_entry() use
in vmx_alloc_
> On 30 Jul 2020, at 20:18, Julien Grall wrote:
>
> From: Julien Grall
>
> We usually have xen/ includes first and then asm/. They are also ordered
> alphabetically among themselves.
>
> Signed-off-by: Julien Grall
Reviewed-by: Bertrand Marquis
> ---
> xen/arch/arm/kernel.c | 10 +---
> On 31 Jul 2020, at 14:53, Bertrand Marquis wrote:
>
>
>
>> On 30 Jul 2020, at 20:18, Julien Grall wrote:
>>
>> From: Julien Grall
>>
>> We usually have xen/ includes first and then asm/. They are also ordered
>> alphabetically among themselves.
>>
>> Signed-off-by: Julien Grall
>
>
> On 30 Jul 2020, at 20:18, Julien Grall wrote:
>
> From: Julien Grall
>
> We usually have xen/ includes first and then asm/. They are also ordered
> alphabetically among themselves.
>
> Signed-off-by: Julien Grall
This could have been merged in patch 3.
But anyway:
Reviewed-by: Bertrand Ma
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes: 37ccb44d0b00 ("xen/gntdev: Implement dma-buf import
From: Oleksandr Andrushchenko
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c
From: Oleksandr Andrushchenko
Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID
request which allows frontends to request EDID structure per
connector. This request is optional and if not supported by the
backend then visible area is still defined by the relevant
XenStore's "resolut
From: Oleksandr Andrushchenko
Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xen/xen_d
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add t
From: Oleksandr Andrushchenko
Hello,
This series contains an assorted set of fixes and improvements for
the Xen para-virtualized display driver and grant device driver which
I have collected over the last couple of months:
1. Minor fixes to grant device driver and drm/xen-front.
2. New format
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to 'ERR_CAST'
> On 30 Jul 2020, at 19:07, Julien Grall wrote:
>
> From: Julien Grall
>
> The function __cmpxchg_mb_timeout() was intended to have the same
> semantics as __cmpxchg_mb(). Unfortunately, the memory barriers were
> not added when first implemented.
>
> There is no known issue with the existi
> On Jul 31, 2020, at 12:29 PM, Jan Beulich wrote:
>
> On 30.07.2020 03:27, Stefano Stabellini wrote:
>> Hi all,
>>
>> I would like to ask for your feedback on the adoption of the kernel-doc
>> format for in-code comments.
>>
>> In the FuSa SIG we have started looking into FuSa documents for
> On 31 Jul 2020, at 13:29, Jan Beulich wrote:
>
> On 30.07.2020 03:27, Stefano Stabellini wrote:
>> Hi all,
>>
>> I would like to ask for your feedback on the adoption of the kernel-doc
>> format for in-code comments.
>>
>> In the FuSa SIG we have started looking into FuSa documents for Xen
> On 30 Jul 2020, at 20:18, Julien Grall wrote:
>
> From: Julien Grall
>
>* Add space before and after operator
>* Align \
>* Format comments
>
> No functional changes expected.
>
> Signed-off-by: Julien Grall
Reviewed-by: Bertrand Marquis
> ---
> xen/include/xen/guest_acces
> On 30 Jul 2020, at 20:18, Julien Grall wrote:
>
> From: Julien Grall
>
> Only a few places are actually including asm/guest_access.h. While this
> is fine today, a follow-up patch will want to move most of the helpers
> from asm/guest_access.h to xen/guest_access.h.
>
> To prepare the mov
> On 30 Jul 2020, at 20:18, Julien Grall wrote:
>
> From: Julien Grall
>
> Only a few places are actually including asm/guest_access.h. While this
> is fine today, a follow-up patch will want to move most of the helpers
> from asm/guest_access.h to xen/guest_access.h.
>
> To prepare the move,
From: Paul Durrant
All non-MMIO ranges (i.e those not mapping real device MMIO regions) that
map valid MFNs are normally marked MTRR_TYPE_WRBACK and 'ipat' is set. Hence
when PV drivers running in a guest populate the BAR space of the Xen Platform
PCI Device with pages such as the Shared Info pag
On 31.07.2020 14:35, Julien Grall wrote:
> Hi Jan,
>
> On 31/07/2020 10:53, Jan Beulich wrote:
>> On 31.07.2020 10:38, Eslam Elnikety wrote:
>>> On 28.07.20 19:51, Jan Beulich wrote:
On 28.07.2020 11:26, Andrew Cooper wrote:
> --- a/xen/include/asm-x86/hvm/vpt.h
> +++ b/xen/include/as
From: Paul Durrant
Re-factor the code to take advantage of the fact that the APIC access page is
a 'special' page.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
---
xen/arch/x86/hvm/mtrr.c | 15 ---
From: Paul Durrant
This series was originally a singleton (of patch #1)
Paul Durrant (2):
x86/hvm: set 'ipat' in EPT for special pages
x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()
xen/arch/x86/hvm/mtrr.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(
On 31.07.2020 14:27, George Dunlap wrote:
>> On Jul 31, 2020, at 1:25 PM, Jan Beulich wrote:
>> On 30.07.2020 17:41, George Dunlap wrote:
On Jul 30, 2020, at 4:17 PM, George Dunlap
wrote:
Hey all,
The community call is scheduled for next week, 6 August. I, however,
Hi Jan,
On 31/07/2020 10:53, Jan Beulich wrote:
On 31.07.2020 10:38, Eslam Elnikety wrote:
On 28.07.20 19:51, Jan Beulich wrote:
On 28.07.2020 11:26, Andrew Cooper wrote:
--- a/xen/include/asm-x86/hvm/vpt.h
+++ b/xen/include/asm-x86/hvm/vpt.h
@@ -73,7 +73,13 @@ struct hpet_registers {
> On Jul 31, 2020, at 1:25 PM, Jan Beulich wrote:
>
> On 30.07.2020 17:41, George Dunlap wrote:
>>> On Jul 30, 2020, at 4:17 PM, George Dunlap wrote:
>>>
>>> Hey all,
>>>
>>> The community call is scheduled for next week, 6 August. I, however, will
>>> be on PTO that week; I propose resche
On 30.07.2020 17:41, George Dunlap wrote:
>> On Jul 30, 2020, at 4:17 PM, George Dunlap wrote:
>>
>> Hey all,
>>
>> The community call is scheduled for next week, 6 August. I, however, will
>> be on PTO that week; I propose rescheduling it for the following week, 13
>> August, at the same time.
On 31/07/2020 13:15, Olaf Hering wrote:
> Am Fri, 31 Jul 2020 13:04:35 +0100
> schrieb Andrew Cooper :
>
>> And in particular, probably missing from libxl_cpuid.c, which I was
>> meaning to check when I've got a free moment.
> Will a ever domU see this flag? I just spotted the <29> when comparing
On 31.07.2020 14:04, Andrew Cooper wrote:
> On 31/07/2020 13:03, Jan Beulich wrote:
>> On 30.07.2020 18:34, Olaf Hering wrote:
>>> Translate <29> into a feature string.
>>>
>>> Signed-off-by: Olaf Hering
>> Acked-by: Jan Beulich
>>
>> Albeit I'm pretty sure there are more missing than just this l
On 30.07.2020 22:50, Julien Grall wrote:
> On 30/07/2020 11:24, Bertrand Marquis wrote:
>> At the moment on Arm, a Linux guest running with KTPI enabled will
>> cause the following error when a context switch happens in user mode:
>> (XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xff837e
Am Fri, 31 Jul 2020 13:04:35 +0100
schrieb Andrew Cooper :
> And in particular, probably missing from libxl_cpuid.c, which I was
> meaning to check when I've got a free moment.
Will a ever domU see this flag? I just spotted the <29> when comparing
'xen-cpuid' output between recent Xen releases.
Stuff the two queries together: we use the firsty query as a WITH
clause. This is significantly faster, perhaps because the query
optimiser does a better job but probably just because it saves on
round trips.
No functional change.
Perf: subjectively this seemed to help when the cache was cold.
Perf: runtime of my test case now ~11s
Example query before (from the Perl DBI trace):
SELECT * FROM flights JOIN steps USING (flight)
WHERE (branch='xen-unstable')
AND job=? and testid=? and status='pass'
AND ( (TRUE AND flight <= 151903) AND (bles
With $dbh_tests->do(...), we can only get a debug trace of the queries
by using DBI_TRACE which produces voluminous output. Using our own
db_prepare invokes our own debugging.
No functional change.
Signed-off-by: Ian Jackson
---
v2: New patch.
---
cs-bisection-step | 6 +++---
1 file changed,
This condition is the same as $flightcond. (This has no effect on the
db performance since the query planner figures it out, but it is
confusing.)
Signed-off-by: Ian Jackson
---
sg-report-host-history | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sg-report-host-history b
This printing has a significant effect on the performance of this
program, at least after we optimise various other things.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/sg-report-host-history b/sg-report-
This obviously-fine change makes the next commit easier to review.
Signed-off-by: Ian Jackson
---
v2: New patch.
---
cs-bisection-step | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cs-bisection-step b/cs-bisection-step
index 5d4e179e..f11726aa 100755
--- a/cs-bisection-
sg-report-host-history is going to want this in a moment
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index 2f81e89d..8e4c5b9a 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Ex
Move the per-host code all into the same per-host loop. One effect is
to transpose the db_retry and host loops for mainquery.
No functional change.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/sg-report-
On 31/07/2020 13:03, Jan Beulich wrote:
> On 30.07.2020 18:34, Olaf Hering wrote:
>> Translate <29> into a feature string.
>>
>> Signed-off-by: Olaf Hering
> Acked-by: Jan Beulich
>
> Albeit I'm pretty sure there are more missing than just this lone one.
And in particular, probably missing from
flight 152311 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152311/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 152293
test-amd64-amd64-xl-qemuu-win7-amd64
On 30.07.2020 18:34, Olaf Hering wrote:
> Translate <29> into a feature string.
>
> Signed-off-by: Olaf Hering
Acked-by: Jan Beulich
Albeit I'm pretty sure there are more missing than just this lone one.
Jan
> --- a/tools/misc/xen-cpuid.c
> +++ b/tools/misc/xen-cpuid.c
> @@ -133,7 +133,7 @@
$parents might be undef here.
Signed-off-by: Ian Jackson
---
New in v2.
---
adhoc-revtuple-generator | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/adhoc-revtuple-generator b/adhoc-revtuple-generator
index c8d6f4ad..ec33305a 100755
--- a/adhoc-revtuple-generator
+++ b/adhoc-
* Make it into a subref which takes a $table argument.
* Change the two references into function calls using the @{...} syntax
* Move the definition earlier in the file
No change to the generated query.
Signed-off-by: Ian Jackson
---
v2: New patch.
---
cs-bisection-step | 16 ++--
1
This moves the loop over hosts into the main program. We are working
our way to a new code structure.
No functional change.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/sg-report-host-history b/sg
Make this bit of query into a subref which takes a $table argument.
No change to the generated query.
Signed-off-by: Ian Jackson
---
v2: New patch.
---
cs-bisection-step | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/cs-bisection-step b/cs-bisection-step
index f1172
1 - 100 of 162 matches
Mail list logo
