On 22.09.20 09:01, SeongJae Park wrote:
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data copy overhead[1] and thus it is
required to be disabled. But, there is no option to disable it. For
the reason, this commit add
flight 154605 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154605/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On 21.09.2020 20:02, Julien Grall wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -504,6 +504,7 @@ static bool propagate_node(unsigned int xmf, unsigned int
> *memflags)
>
> static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t)
> arg)
> {
> +#ifdef CONF
On 22.09.20 08:56, Paolo Bonzini wrote:
> On 22/09/20 08:45, David Hildenbrand wrote:
>>> It's certainly a good idea but it's quite verbose.
>>>
>>> What about using atomic__* as the prefix? It is not very common in QEMU
>>> but there are some cases (and I cannot think of anything better).
>>
>> a
Later additions look to have been put at the end, with MEM_ACCESS*
somewhere in the middle. Re-sort this part of the file, in the hope that
future additions will be made noticing the intentions here.
Signed-off-by: Jan Beulich
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -34,16 +34,11 @@
On 21.09.2020 20:02, Julien Grall wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -63,6 +63,9 @@ config HAS_IOPORTS
> config HAS_SCHED_GRANULARITY
> bool
>
> +config HAS_M2P
> + bool
Following Andrew's comments I think the need for this addition
disappears, but in ca
On 21.09.2020 20:02, Julien Grall wrote:
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -685,4 +685,17 @@ static inline void put_page_alloc_ref(struct page_info
> *page)
> }
> }
>
> +/*
> + * Dummy implementation of M2P-related helpers for common code when
> + * the archite
On Mon, Sep 21, 2020 at 01:56:08PM -0700, no-re...@patchew.org wrote:
> ERROR: Macros with multiple statements should be enclosed in a do - while loop
> #2968: FILE: include/qemu/atomic.h:152:
> +#define qemu_atomic_rcu_read__nocheck(ptr, valptr) \
> __atomic_load(ptr, valptr, __ATOMIC_RE
On Tue, Sep 22, 2020 at 08:56:06AM +0200, Paolo Bonzini wrote:
> On 22/09/20 08:45, David Hildenbrand wrote:
> >> It's certainly a good idea but it's quite verbose.
> >>
> >> What about using atomic__* as the prefix? It is not very common in QEMU
> >> but there are some cases (and I cannot think o
On 22/09/2020 07:22, Christoph Hellwig wrote:
On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote:
This is awkward. I'd like it if we had a vfree() variant which called
put_page() instead of __free_pages(). I'd like it even more if we
used release_pages() instead of our own loop t
On 21.09.2020 13:39, Julien Grall wrote:
> On 21/09/2020 11:17, Jan Beulich wrote:
>> On 14.09.2020 12:15, Jan Beulich wrote:
>>> Switch to $(call if_changed,ld) where possible; presumably not doing so
>>> in e321576f4047 ("xen/build: start using if_changed") right away was an
>>> oversight, as it
On 9/22/20 10:17 AM, Stefan Hajnoczi wrote:
> On Mon, Sep 21, 2020 at 01:56:08PM -0700, no-re...@patchew.org wrote:
>> ERROR: Macros with multiple statements should be enclosed in a do - while
>> loop
>> #2968: FILE: include/qemu/atomic.h:152:
>> +#define qemu_atomic_rcu_read__nocheck(ptr, valptr)
On 19.09.20 05:17, Jing Xiangfeng wrote:
After commit 9f51c05dc41a ("pvcalls-front: Avoid
get_free_pages(GFP_KERNEL) under spinlock"), the variable ret is being
initialized with '-ENOMEM' that is meaningless. So remove it.
Signed-off-by: Jing Xiangfeng
Reviewed-by: Juergen Gross
Juergen
On Mon, Sep 21, 2020 at 04:29:10PM -0500, Eric Blake wrote:
> On 9/21/20 11:23 AM, Stefan Hajnoczi wrote:
Thanks for the review! Your feedback prompted me to do this more
systematically. I fixed the command-lines and published a diff of just
the manual changes I made on top of the mechanical chang
Hi Jan,
On 22/09/2020 08:47, Jan Beulich wrote:
Later additions look to have been put at the end, with MEM_ACCESS*
somewhere in the middle. Re-sort this part of the file, in the hope that
future additions will be made noticing the intentions here.
Signed-off-by: Jan Beulich
Acked-by: Julien
Hi Jan,
On 22/09/2020 09:28, Jan Beulich wrote:
On 21.09.2020 13:39, Julien Grall wrote:
On 21/09/2020 11:17, Jan Beulich wrote:
On 14.09.2020 12:15, Jan Beulich wrote:
Switch to $(call if_changed,ld) where possible; presumably not doing so
in e321576f4047 ("xen/build: start using if_changed"
On 08/09/20 17:55, Philippe Mathieu-Daudé wrote:
> Hard to make an exciting cover of this series.
>
> Basically:
> - Make better separation between Xen accel and Xen hardware,
> - Move stuff around to restrict PCMachineState to hw/i386/.
>
> Since v1:
> - added missing include in stubs/xen-hw-stu
On 22.09.20 09:33, Jan Beulich wrote:
Hi Jan
On 21.09.2020 21:02, Oleksandr wrote:
On 14.09.20 17:17, Jan Beulich wrote:
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
--- /dev/null
+++ b/xen/include/xen/ioreq.h
@@ -0,0 +1,82 @@
+/*
+ * ioreq.h: Hardware virtual machine assist interface
Hi Julie,
Julien Grall writes:
> From: Julien Grall
>
> Add emacs magics for xen/guest_access.h and
> asm-x86/guest_access.h.
As Emacs user I fully approve this.
But I want to hijack this thread a little to discuss even better
solution. Emacs supports .dir-locals.el file [1], which allows to
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data copy overheads[1] and thus it is
required to be disabled. But, there is no option to disable it. For
the reason, this commit adds a module parameter for disabling of the
From: SeongJae Park
Commit 14e710fe7897 ("xen-blkfront: rename indirect descriptor
parameter") changed the name of the module parameter for the maximum
amount of segments in indirect requests but missed updating the
document. This commit updates the document.
Signed-off-by: SeongJae Park
---
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data copy overheads[1] and thus it is
required to be disabled. But, there is no option to disable it. For
the reason, this commit adds module parameters for disabling of the
On 22.09.2020 11:58, Oleksandr wrote:
> On 22.09.20 09:33, Jan Beulich wrote:
>> On 21.09.2020 21:02, Oleksandr wrote:
>>> On 14.09.20 17:17, Jan Beulich wrote:
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
> +#define GET_IOREQ_SERVER(d, id) \
> +(d)->arch.hvm.ioreq_server.serve
On 22.09.2020 11:24, Julien Grall wrote:
> On 22/09/2020 09:28, Jan Beulich wrote:
>> On 21.09.2020 13:39, Julien Grall wrote:
>>> On 21/09/2020 11:17, Jan Beulich wrote:
On 14.09.2020 12:15, Jan Beulich wrote:
> Switch to $(call if_changed,ld) where possible; presumably not doing so
>
Fix two issues in mini-os netfront:
- undo init_netfront interface change and replace it with an alternative
- fix mini-os suspend/resume handling in netfront
Juergen Gross (2):
mini-os: netfront: retrieve netmask and gateway via extra function
mini-os: netfront: fix suspend/resume handling
Suspend/resume handling of netfront is completely broken from the
beginning. Commit d225f4012d69a1 ("Save/Restore Support: Add
suspend/restore support for netfront") introduced a new structure
netfront_dev_list referencing the real struct netfront_dev elements.
This list is used to setup the device
Commit 1b8ed31f4ce40 ("mini-os: netfront: Read netmask and gateway from
Xenstore") modified init_netfront() to take two additional parameters.
This broke the Xen build as init_netfront() is used in grub stubdom,
too.
So instead of tightly coupling Mini-OS and Xen build via this interface
modificat
On Tue, Sep 22, 2020 at 08:22:49AM +0200, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote:
> > This is awkward. I'd like it if we had a vfree() variant which called
> > put_page() instead of __free_pages(). I'd like it even more if we
> > used release_pag
flight 154592 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 18 guest-start/debianhvm.repeat fail
REGR. vs. 154556
On Tue, 22 Sep 2020 13:12:59 +0200 "Roger Pau Monné"
wrote:
> On Tue, Sep 22, 2020 at 12:52:07PM +0200, SeongJae Park wrote:
> > From: SeongJae Park
> >
> > Persistent grants feature provides high scalability. On some small
> > systems, however, it could incur data copy overheads[1] and thus
On Tue, Sep 22, 2020 at 09:01:25AM +0200, SeongJae Park wrote:
> From: SeongJae Park
>
> Persistent grants feature provides high scalability. On some small
> systems, however, it could incur data copy overhead[1] and thus it is
> required to be disabled. But, there is no option to disable it.
On 22/09/20 10:58, Stefan Hajnoczi wrote:
> clang's C11 atomic_fetch_*() functions only take a C11 atomic type
> pointer argument. QEMU uses direct types (int, etc) and this causes a
> compiler error when a QEMU code calls these functions in a source file
> that also included via a system header f
On 22.09.20 13:26, SeongJae Park wrote:
On Tue, 22 Sep 2020 13:12:59 +0200 "Roger Pau Monné"
wrote:
On Tue, Sep 22, 2020 at 12:52:07PM +0200, SeongJae Park wrote:
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data c
Hi Jan,
On 22/09/2020 11:55, Jan Beulich wrote:
On 22.09.2020 11:24, Julien Grall wrote:
On 22/09/2020 09:28, Jan Beulich wrote:
On 21.09.2020 13:39, Julien Grall wrote:
On 21/09/2020 11:17, Jan Beulich wrote:
On 14.09.2020 12:15, Jan Beulich wrote:
Switch to $(call if_changed,ld) where pos
flight 154609 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154609/
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 Tue, 22 Sep 2020 13:35:11 +0200 "Roger Pau Monné"
wrote:
> On Tue, Sep 22, 2020 at 01:26:38PM +0200, SeongJae Park wrote:
> > On Tue, 22 Sep 2020 13:12:59 +0200 "Roger Pau Monné"
> > wrote:
> >
> > > On Tue, Sep 22, 2020 at 12:52:07PM +0200, SeongJae Park wrote:
> > > > From: SeongJae Park
On Tue, 22 Sep 2020 13:35:30 +0200 "Jürgen Groß" wrote:
> On 22.09.20 13:26, SeongJae Park wrote:
> > On Tue, 22 Sep 2020 13:12:59 +0200 "Roger Pau Monné"
> > wrote:
> >
> >> On Tue, Sep 22, 2020 at 12:52:07PM +0200, SeongJae Park wrote:
> >>> From: SeongJae Park
> >>>
> >>> Persistent grants
On 22.09.20 12:52, SeongJae Park wrote:
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data copy overheads[1] and thus it is
required to be disabled. It can be disabled from blkback side using a
module parameter, 'featur
With commit 68a8aa5d72 the build randomly fails. Up to commit c7e3021a71 no
errors (like this) are seen. For some reason nothing below tools/ was touched
in this range, so the bug may already exist for a while.
attempt on host#1:
[ 81s] ln: failed to create symbolic link
'/home/abuild/rpmbuil
On Mon, Sep 21, 2020 at 05:49:45PM +0200, Jan Beulich wrote:
> On 21.09.2020 17:35, Roger Pau Monné wrote:
> > On Mon, Sep 21, 2020 at 04:22:26PM +0200, Jan Beulich wrote:
> >> On 10.09.2020 15:35, Roger Pau Monne wrote:
> >>> arch_init_memory will treat all the gaps on the physical memory map
> >>
On Tue, 22 Sep 2020 14:11:32 +0200 "Jürgen Groß" wrote:
> On 22.09.20 12:52, SeongJae Park wrote:
> > From: SeongJae Park
> >
> > Persistent grants feature provides high scalability. On some small
> > systems, however, it could incur data copy overheads[1] and thus it is
> > required to be dis
flight 154600 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154600/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 6 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On Mon, Sep 14, 2020 at 04:27:45PM +0100, Andrew Cooper wrote:
> On 14/09/2020 15:50, Dmitry Fedorov wrote:
> > Hi,
> >
> > Implementing qrexec+usbip+qemu in Linux-based stub domain leads me to
> > an issue where a device model stub domain doesn't have maptrack entries.
> >
> > Would it be possible
On 22.09.2020 15:10, Andrew Cooper wrote:
> On 29/07/2020 21:02, Jan Beulich wrote:
>> On 28.07.2020 13:37, Andrew Cooper wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -4013,6 +4013,72 @@ static int gnttab_get_shared_frame_mfn(struct
>>> domain *d,
>>> re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-25598 / XSA-334
version 3
Missing unlock in XENMEM_acquire_resource error path
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-25602 / XSA-333
version 3
x86 pv: Crash when handling guest access to MSR_MISC_ENABLE
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-25596 / XSA-339
version 3
x86 pv guest kernel DoS via SYSENTER
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-25604 / XSA-336
version 3
race when migrating timers between x86 HVM vCPU-s
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-25597 / XSA-338
version 4
once valid event channels may not turn invalid
UPDATES IN VERSION 4
Public release.
ISSUE DESCRIPTION
===
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-25600 / XSA-342
version 3
out of bounds event channels available to 32-bit x86 domains
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
===
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-25603 / XSA-340
version 3
Missing memory barriers when accessing/allocating an event channel
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-25601 / XSA-344
version 4
lack of preemption in evtchn_reset() / evtchn_destroy()
UPDATES IN VERSION 4
Public release.
ISSUE DESCRIPTION
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-25595 / XSA-337
version 3
PCI passthrough code reading back hardware registers
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
On 22.09.20 14:17, Olaf Hering wrote:
With commit 68a8aa5d72 the build randomly fails. Up to commit c7e3021a71 no
errors (like this) are seen. For some reason nothing below tools/ was touched
in this range, so the bug may already exist for a while.
attempt on host#1:
[ 81s] ln: failed to cre
> -Original Message-
> From: Edwin Torok
> Sent: 22 September 2020 14:29
> To: sstabell...@kernel.org; Anthony Perard ; xen-
> de...@lists.xenproject.org; p...@xen.org
> Cc: xen-us...@lists.xenproject.org; jerome.lesei...@gmail.com; jul...@xen.org
> Subject: Re: oxenstored performance issu
Am Tue, 22 Sep 2020 15:51:00 +0200
schrieb Jürgen Groß :
> Is this really a normal upstream build, or do you have any additional
> patches applied?
Nothing relevant.
https://github.com/olafhering/xen/compare/olafhering:olh-base-staging...olh-fixes-staging
Maybe the build VMs have filesystem issu
On 22.09.20 15:42, Paul Durrant wrote:
-Original Message-
From: Edwin Torok
Sent: 22 September 2020 14:29
To: sstabell...@kernel.org; Anthony Perard ; xen-
de...@lists.xenproject.org; p...@xen.org
Cc: xen-us...@lists.xenproject.org; jerome.lesei...@gmail.com; jul...@xen.org
Subject: Re:
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data copy overheads[1] and thus it is
required to be disabled. But, there is no option to disable it. For
the reason, this commit adds module parameters for disabling of the
> -Original Message-
> From: Jürgen Groß
> Sent: 22 September 2020 15:18
> To: p...@xen.org; 'Edwin Torok' ;
> sstabell...@kernel.org; 'Anthony Perard'
> ; xen-devel@lists.xenproject.org
> Cc: xen-us...@lists.xenproject.org; jerome.lesei...@gmail.com; jul...@xen.org
> Subject: Re: oxensto
On 22.09.20 16:15, SeongJae Park wrote:
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data copy overheads[1] and thus it is
required to be disabled. But, there is no option to disable it. For
the reason, this commit ad
On 22.09.20 16:15, SeongJae Park wrote:
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data copy overheads[1] and thus it is
required to be disabled. It can be disabled from blkback side using a
module parameter, 'featur
On 22.09.20 16:15, SeongJae Park wrote:
From: SeongJae Park
Commit 14e710fe7897 ("xen-blkfront: rename indirect descriptor
parameter") changed the name of the module parameter for the maximum
amount of segments in indirect requests but missed updating the
document. This commit updates the docu
On Tue, Sep 22, 2020 at 09:23:59AM +0100, Tvrtko Ursulin wrote:
> If I understood this sub-thread correctly, iterating and freeing the pages
> via the vmapped ptes, so no need for a
> shmem_read_mapping_page_gfp loop in shmem_unpin_map looks plausible to me.
>
> I did not get the reference to kern
On Tue, Sep 22, 2020 at 12:21:44PM +0100, Matthew Wilcox wrote:
> Actually, vfree() will work today; I cc'd you on a documentation update
> to make it clear that this is permitted.
vfree calls __free_pages, the i915 and a lot of other code calls
put_page. They are mostly the same, but not quite a
On Tue, Sep 22, 2020 at 04:39:06PM +0200, Christoph Hellwig wrote:
> On Tue, Sep 22, 2020 at 12:21:44PM +0100, Matthew Wilcox wrote:
> > Actually, vfree() will work today; I cc'd you on a documentation update
> > to make it clear that this is permitted.
>
> vfree calls __free_pages, the i915 and a
On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
> This will end up incrementing area->ptes pointer. So perhaps something like
>
>
> pte_t **ptes = area->ptes;
>
> if (apply_to_page_range(&init_mm, (unsigned long)area->area->addr,
> PAGE_SIZE *
On Tue, 22 Sep 2020 16:44:25 +0200 "Roger Pau Monné"
wrote:
> On Tue, Sep 22, 2020 at 04:27:39PM +0200, Jürgen Groß wrote:
> > On 22.09.20 16:15, SeongJae Park wrote:
> > > From: SeongJae Park
> > >
> > > Commit 14e710fe7897 ("xen-blkfront: rename indirect descriptor
> > > parameter") changed
On 22.09.20 13:54, Jan Beulich wrote:
Hi Jan
On 22.09.2020 11:58, Oleksandr wrote:
On 22.09.20 09:33, Jan Beulich wrote:
On 21.09.2020 21:02, Oleksandr wrote:
On 14.09.20 17:17, Jan Beulich wrote:
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
+#define GET_IOREQ_SERVER(d, id) \
+(d
On Tue, Sep 22, 2020 at 12:52:07PM +0200, SeongJae Park wrote:
> From: SeongJae Park
>
> Persistent grants feature provides high scalability. On some small
> systems, however, it could incur data copy overheads[1] and thus it is
> required to be disabled. But, there is no option to disable it.
On 9/22/20 10:58 AM, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
>> This will end up incrementing area->ptes pointer. So perhaps something like
>>
>>
>> pte_t **ptes = area->ptes;
>>
>> if (apply_to_page_range(&init_mm, (unsigned long)are
On Tue, Sep 22, 2020 at 11:24:20AM -0400, boris.ostrov...@oracle.com wrote:
>
> On 9/22/20 10:58 AM, Christoph Hellwig wrote:
> > On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
> >> This will end up incrementing area->ptes pointer. So perhaps something like
> >>
> >>
>
On 9/22/20 11:27 AM, Christoph Hellwig wrote:
> On Tue, Sep 22, 2020 at 11:24:20AM -0400, boris.ostrov...@oracle.com wrote:
>> On 9/22/20 10:58 AM, Christoph Hellwig wrote:
>>> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
This will end up incrementing area->pte
On Tue, Sep 22, 2020 at 01:26:38PM +0200, SeongJae Park wrote:
> On Tue, 22 Sep 2020 13:12:59 +0200 "Roger Pau Monné"
> wrote:
>
> > On Tue, Sep 22, 2020 at 12:52:07PM +0200, SeongJae Park wrote:
> > > From: SeongJae Park
> > >
> > > Persistent grants feature provides high scalability. On som
On 22.09.2020 17:05, Oleksandr wrote:
> 2. *arch.hvm.params*: Two functions that use it
> (hvm_alloc_legacy_ioreq_gfn/hvm_free_legacy_ioreq_gfn) either go into
> arch code completely or
> specific macro is used in common code:
>
> #define ioreq_get_params(d, i) ((d)->arch.hvm.params[i])
On 22.09.2020 16:50, Andrew Cooper wrote:
> On 22/09/2020 14:34, Jan Beulich wrote:
>> On 22.09.2020 15:10, Andrew Cooper wrote:
>>> On 29/07/2020 21:02, Jan Beulich wrote:
On 28.07.2020 13:37, Andrew Cooper wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
>
On 22/09/2020 15:31, Christoph Hellwig wrote:
On Tue, Sep 22, 2020 at 09:23:59AM +0100, Tvrtko Ursulin wrote:
If I understood this sub-thread correctly, iterating and freeing the pages
via the vmapped ptes, so no need for a
shmem_read_mapping_page_gfp loop in shmem_unpin_map looks plausible to
On 14.09.20 17:59, Jan Beulich wrote:
Hi Jan
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -35,6 +35,13 @@ static inline struct hvm_ioreq_server
*get_ioreq_server(const struct domain *d,
return GET_IOREQ_SERVER(d, id);
On 9/21/20 5:54 PM, Anchal Agarwal wrote:
> Thanks for the above suggestion. You are right I didn't find a way to declare
> a global state either. I just broke the above check in 2 so that once we have
> support for ARM we should be able to remove aarch64 condition easily. Let me
> know if I am m
On 14.09.20 18:10, Jan Beulich wrote:
Hi Jan
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
--- a/xen/common/ioreq.c
+++ b/xen/common/ioreq.c
@@ -189,7 +189,7 @@ bool handle_hvm_io_completion(struct vcpu *v)
break;
case HVMIO_mmio_completion:
-return handle_mmio
On 14.09.20 18:13, Jan Beulich wrote:
Hi Jan
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these helpers will be used
on Arm as is. Move them to include/xen/ioreq.h
I think you also want to renamed them to replace the hvm
flight 154601 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154601/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 154121
test-amd64-i386-xl-pvshim12
On 14.09.20 18:16, Jan Beulich wrote:
Hi Jan
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -23,6 +23,40 @@
#include
+struct hvm_ioreq_page {
+gfn_t gfn;
+struct page_info *page;
+void *va;
+};
+
+struct h
On Tue, Sep 22, 2020 at 05:13:45PM +0100, Tvrtko Ursulin wrote:
>> void *shmem_pin_map(struct file *file)
>> {
>> -const size_t n_pte = shmem_npte(file);
>> -pte_t *stack[32], **ptes, **mem;
>
> Chris can comment how much he'd miss the 32 page stack shortcut.
I'd like to see a profile
On 14.09.20 18:56, Jan Beulich wrote:
Hi Jan
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -150,6 +150,18 @@ do_dm_op(
unsigned int nr_bufs,
XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs);
+struct dmop_arg
On 22/09/2020 17:33, Christoph Hellwig wrote:
On Tue, Sep 22, 2020 at 05:13:45PM +0100, Tvrtko Ursulin wrote:
void *shmem_pin_map(struct file *file)
{
- const size_t n_pte = shmem_npte(file);
- pte_t *stack[32], **ptes, **mem;
Chris can comment how much he'd miss the 32 pag
On 16.09.20 10:51, Jan Beulich wrote:
Hi Jan
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
@@ -2277,8 +2299,10 @@ void leave_hypervisor_to_guest(void)
{
local_irq_disable();
-check_for_vcpu_work();
-check_for_pcpu_work();
+do
+{
+check_for_pcpu_work();
On 29/07/2020 21:02, Jan Beulich wrote:
> On 28.07.2020 13:37, Andrew Cooper wrote:
>> The existing logic doesn't function in the general case for mapping a
>> guests
>> grant table, due to arbitrary 32 frame limit, and the default grant
>> table
>> limit being 64.
>>
>> In order to start addressin
On 30/07/2020 09:14, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 28 July 2020 12:37
>> To: Xen-devel
>> Cc: Andrew Cooper ; George Dunlap
>> ; Ian
>> Jackson ; Jan Beulich ; Konrad
>> Rzeszutek Wilk
>> ; Stefano Stabellini ; Wei
>> Liu ; Julien
>> Grall ;
flight 154615 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154615/
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 Tue, 2020-09-22 at 15:17 +0200, jerome leseinne wrote:
> Hi,
>
> Edwin you rock ! This call in qemu is effectively the culprit !
> I have disabled this xen_bus_add_watch call and re-run test on our
> big server:
>
> - oxenstored is now between 10% to 20% CPU usage (previously was
> 100% all
On 16.09.20 11:55, Julien Grall wrote:
Hi Julien, Jan
On 16/09/2020 09:52, Jan Beulich wrote:
On 16.09.2020 10:50, Julien Grall wrote:
On 16/09/2020 08:17, Jan Beulich wrote:
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
for ( i = 0; !rc && i < xmar.nr_frames; i++ )
On Tue, 22 Sep 2020, Julien Grall wrote:
> Hi Jan,
>
> On 22/09/2020 11:55, Jan Beulich wrote:
> > On 22.09.2020 11:24, Julien Grall wrote:
> > > On 22/09/2020 09:28, Jan Beulich wrote:
> > > > On 21.09.2020 13:39, Julien Grall wrote:
> > > > > On 21/09/2020 11:17, Jan Beulich wrote:
> > > > > > O
Hi Andrew,
On 21/09/2020 20:46, Andrew Cooper wrote:
On 21/09/2020 19:02, Julien Grall wrote:
From: Julien Grall
XENMEM_exchange can only be used by PV guest but the check is well
hidden in steal_page(). This is because paging_model_external() will
return false only for PV domain.
To make cl
Hi Jan,
On 22/09/2020 08:35, Jan Beulich wrote:
On 21.09.2020 20:02, Julien Grall wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -504,6 +504,7 @@ static bool propagate_node(unsigned int xmf, unsigned int
*memflags)
static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memo
On 22/09/2020 14:51, Jürgen Groß wrote:
> On 22.09.20 14:17, Olaf Hering wrote:
>> With commit 68a8aa5d72 the build randomly fails. Up to commit
>> c7e3021a71 no errors (like this) are seen. For some reason nothing
>> below tools/ was touched in this range, so the bug may already exist
>> for a whi
Hi Andrew,
On 21/09/2020 21:29, Andrew Cooper wrote:
On 21/09/2020 19:02, Julien Grall wrote:
From: Julien Grall
While Arm never had a M2P, the implementation of mfn_to_gmfn is pretty
bogus as we directly return the MFN passed in parameter.
Thankfully, the use of mfn_to_gmfn is pretty limite
Hi Jan,
On 22/09/2020 08:54, Jan Beulich wrote:
On 21.09.2020 20:02, Julien Grall wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -63,6 +63,9 @@ config HAS_IOPORTS
config HAS_SCHED_GRANULARITY
bool
+config HAS_M2P
+ bool
Following Andrew's comments I think the
On 16.09.20 11:04, Jan Beulich wrote:
Hi Jan
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch introduces a helper the main purpose of which is to check
if a domain is using IOREQ server(s).
On Arm the benefit is to avoid calling handle_hvm_io_completi
On 21/09/2020 21:34, Andrew Cooper wrote:
On 21/09/2020 19:02, Julien Grall wrote:
From: Julien Grall
On x86, mfn_to_gmfn can be replaced with mfn_to_gfn. On Arm, there are
no more call to mfn_to_gmfn, so the helper can be dropped.
The previous patch dropped the mfn_to_gmfn() call from th
It's dead code, even more now that read_msi_msg has been removed.
Suggested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hpet.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/xen/arch/x86/hpet.c b/xen/arch/x86/hpet.c
index 154c67423b..a55e68e6f7 100644
--- a/x
1 - 100 of 148 matches
Mail list logo
