> -Original Message-
> From: Philippe Mathieu-Daudé On Behalf Of
> Philippe Mathieu-Daudé
> Sent: 20 September 2020 12:44
> To: Markus Armbruster ; qemu-de...@nongnu.org
> Cc: Laurent Vivier ; Paolo Bonzini ;
> Anthony Perard
> ; Stefano Stabellini ;
> Daniel P. Berrangé
> ; Eduardo Hab
> -Original Message-
> From: Xen-devel On Behalf Of Ian
> Jackson
> Sent: 18 September 2020 17:39
> To: Debian folks: Michael Tokarev ; Hans van Kranenburg
> ; Xen
> upstream folks with an interest: Andrew Cooper ;
> Roger Pau Monné
>
> Cc: pkg-xen-de...@lists.alioth.debian.org; xen-de
Philippe Mathieu-Daudé writes:
> Commit 9940b2cfbc0 introduced qdev_realize() and qbus_realize()
> with the ability to return a boolean value if an error occured,
> thus the caller does not need to check if the Error* pointer is
> set.
> Provide the same ability to the BusRealize type.
>
> Signed
flight 154552 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154552/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 152631
test-amd64-i386-x
On 9/21/20 10:19 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> Commit 9940b2cfbc0 introduced qdev_realize() and qbus_realize()
>> with the ability to return a boolean value if an error occured,
>> thus the caller does not need to check if the Error* pointer is
>> set.
>> Prov
On 21.09.2020 09:36, Paul Durrant wrote:
>> From: Xen-devel On Behalf Of Ian
>> Jackson
>> Sent: 18 September 2020 17:39
>>
>> xc_domain_iomem_permission
>> xc_domain_populate_physmap_exact
>> xc_domain_ioport_mapping
>> xc_domain_memory_mapping
>>
>> The things done by these calls in qemu should
> -Original Message-
> From: Jan Beulich
> Sent: 21 September 2020 10:41
> To: p...@xen.org
> Cc: 'Ian Jackson' ; 'Debian folks: Michael Tokarev'
> ; 'Hans van
> Kranenburg' ; 'Xen upstream folks with an interest: Andrew
> Cooper'
> ; 'Roger Pau Monné' ;
> pkg-xen-
> de...@lists.alioth.
flight 154558 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154558/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ea9af51479fe04955443f0d366376a1008f07c94
baseline version:
ovmf 7faece69854cbcc593643
On 21.08.2020 09:45, Jan Beulich wrote:
> On 20.08.2020 18:28, Andrew Cooper wrote:
>> On 20/08/2020 16:34, Roger Pau Monne wrote:
>>> Currently the dpci EOI callback is only executed for specific EOIs.
>>> This is wrong as non-specific EOIs will also clear the ISR bit and
>>> thus end the interrup
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 did for Arm in (just) one case. It failed to add
> prelink.o to $(targets), though, causing
> -Original Message-
> From: Roger Pau Monné
> Sent: 21 September 2020 11:16
> To: p...@xen.org
> Cc: 'Ian Jackson' ; 'Debian folks: Michael Tokarev'
> ; 'Hans van
> Kranenburg' ; 'Xen upstream folks with an interest: Andrew
> Cooper'
> ; pkg-xen-de...@lists.alioth.debian.org;
> xen-dev
(+ Xen-devel)
Sorry I forgot to CC xen-devel.
On 21/09/2020 12:38, Julien Grall wrote:
Hi all,
I have started to look at the deferral code (see
vcpu_start_shutdown_deferral()) because we need it for LiveUpdate and
Arm will soon use it.
The current implementation is using an smp_mb() to ens
Hi Jan,
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 did for Arm in (just) one case. It failed to a
On Friday, September 18, 2020 11:15 AM, Jan Beulich wrote:
> On 17.09.2020 17:40, Trammell Hudson wrote:
> Instead of forcing the caller to pass in a dot-prefixed name
> and you assuming it's a dot here, how about ...
> ... pe_find_section() looking for '.' followed by ?
v6 adds a special name co
This patch adds support for bundling the xen.efi hypervisor, the xen.cfg
configuration file, the Linux kernel and initrd, as well as the XSM,
and architectural specific files into a single "unified" EFI executable.
This allows an administrator to update the components independently
without requirin
This patch series adds support for bundling the xen.efi hypervisor,
the xen.cfg configuration file, the Linux kernel and initrd, as well
as the XSM, and architectural specific files into a single "unified"
EFI executable. This allows an administrator to update the components
independently without
Add a separate function to display the address ranges used by
the files and call `efi_arch_handle_module()` on the modules.
Signed-off-by: Trammell Hudson
Acked-by: Jan Beulich
---
xen/common/efi/boot.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --
Other than the config file parser that edits the image inplace,
no other users of the file sections requires write access to the
data.
Signed-off-by: Trammell Hudson
Reviewed-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
xen/common/efi/boot.c | 11 ++-
1 file changed, 6 insertions(+
If a unified Xen image is used, then the bundled configuration,
Xen command line, dom0 kernel, and ramdisk are prefered over
any files listed in the config file or provided on the command line.
Unlike the shim based verification, the PE signature on a unified image
covers all of the Xen+config+ker
The config file, kernel, initrd, etc should only be freed if they
are allocated with the UEFI allocator.
Signed-off-by: Trammell Hudson
Reviewed-by: Roger Pau Monné
---
xen/common/efi/boot.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/common/efi/boot.c b/x
On 21.09.2020 13:47, Trammell Hudson wrote:
> On Friday, September 18, 2020 11:15 AM, Jan Beulich wrote:
>> On 17.09.2020 17:40, Trammell Hudson wrote:
>> Instead of forcing the caller to pass in a dot-prefixed name
>> and you assuming it's a dot here, how about ...
>> ... pe_find_section() lookin
On 14.09.20 16:52, Jan Beulich wrote:
Hi Jan
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
prepares IOREQ support before moving to the common code. This way
we will get almost a verbatim copy for
> On 18 Sep 2020, at 18:11, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, Xen will stop processing the Device Tree if a memory
> bank is empty (size == 0).
>
> Unfortunately, some of the Device Tree (such as on Colibri imx8qxp)
> may contain such a bank. This means Xen will
On 21.09.2020 14:22, Oleksandr wrote:
> On 14.09.20 16:52, Jan Beulich wrote:
>> On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
>>> --- a/xen/arch/x86/hvm/ioreq.c
>>> +++ b/xen/arch/x86/hvm/ioreq.c
>>> @@ -170,6 +170,29 @@ static bool hvm_wait_for_io(struct hvm_ioreq_vcpu *sv,
>>> ioreq_t *p)
>>
On 21.09.20 15:31, Jan Beulich wrote:
Hi
On 21.09.2020 14:22, Oleksandr wrote:
On 14.09.20 16:52, Jan Beulich wrote:
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -170,6 +170,29 @@ static bool hvm_wait_for_io(struct hvm_io
> -Original Message-
> From: Julien Grall
> Sent: 21 September 2020 12:41
> To: Jan Beulich ; Stefano Stabellini
> ;
> andrew.coop...@citrix.com; George Dunlap ; Durrant,
> Paul
>
> Cc: Xia, Hongyan ; xen-devel@lists.xenproject.org
> Subject: RE: [EXTERNAL] Memory ordering question in t
Philippe Mathieu-Daudé writes:
> On 9/21/20 10:19 AM, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé writes:
>>
>>> Commit 9940b2cfbc0 introduced qdev_realize() and qbus_realize()
>>> with the ability to return a boolean value if an error occured,
>>> thus the caller does not need to check
On 21.09.2020 13:40, Julien Grall wrote:
> (+ Xen-devel)
>
> Sorry I forgot to CC xen-devel.
>
> On 21/09/2020 12:38, Julien Grall wrote:
>> Hi all,
>>
>> I have started to look at the deferral code (see
>> vcpu_start_shutdown_deferral()) because we need it for LiveUpdate and
>> Arm will soon u
flight 154569 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154569/
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 21/09/2020 13:55, Durrant, Paul wrote:
-Original Message-
From: Julien Grall
Sent: 21 September 2020 12:41
To: Jan Beulich ; Stefano Stabellini
;
andrew.coop...@citrix.com; George Dunlap ; Durrant,
Paul
Cc: Xia, Hongyan ; xen-devel@lists.xenproject.org
Subject: RE: [EXTERNAL] Me
On 21.09.2020 14:47, Oleksandr wrote:
> On 21.09.20 15:31, Jan Beulich wrote:
>> On 21.09.2020 14:22, Oleksandr wrote:
>>> On 14.09.20 16:52, Jan Beulich wrote:
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
> @@ -1215,8 +1233,7 @@ void hvm_destroy_all_ioreq_servers(struct domain *d)
>>>
On Mon, 2020-09-21 at 12:55 +, Durrant, Paul wrote:
> > -Original Message-
> > From: Julien Grall
> > Sent: 21 September 2020 12:41
> > To: Jan Beulich ; Stefano Stabellini <
> > sstabell...@kernel.org>;
> > andrew.coop...@citrix.com; George Dunlap
> > ; Durrant, Paul
> >
> > Cc: Xia
On 21.09.2020 15:27, Julien Grall wrote:
> I think this part is racy at least on non-x86 platform as x86 seems to
> implement smp_mb() with a strong memory barrier (mfence).
The "strength" of the memory barrier doesn't matter here imo. It's
the fully coherent memory model (for WB type memory) whi
> -Original Message-
> From: Jan Beulich
> Sent: 21 September 2020 14:32
> To: Julien Grall
> Cc: Durrant, Paul ; Stefano Stabellini
> ;
> andrew.coop...@citrix.com; George Dunlap ; Xia,
> Hongyan
> ; xen-devel@lists.xenproject.org
> Subject: RE: [EXTERNAL] Memory ordering question in t
On 21.09.2020 15:04, Andrew Cooper wrote:
> MFENCE is overly heavyweight for SMP semantics on WB memory, because it also
> orders weaker cached writes, and flushes the WC buffers.
>
> This technique was used as an optimisation in Java[1], and later adopted by
> Linux[2] where it was measured to ha
On 21.09.2020 15:35, Durrant, Paul wrote:
>> From: Jan Beulich
>> Sent: 21 September 2020 14:32
>>
>> On 21.09.2020 15:27, Julien Grall wrote:
>>> I think this part is racy at least on non-x86 platform as x86 seems to
>>> implement smp_mb() with a strong memory barrier (mfence).
>>
>> The "strengt
On Mon, Sep 21, 2020 at 08:36:55AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel On Behalf Of Ian
> > Jackson
> > Sent: 18 September 2020 17:39
> > To: Debian folks: Michael Tokarev ; Hans van Kranenburg
> > ; Xen
> > upstream folks with an interest: Andrew Cooper
Hi Jan,
On 21/09/2020 14:11, Jan Beulich wrote:
On 21.09.2020 13:40, Julien Grall wrote:
(+ Xen-devel)
Sorry I forgot to CC xen-devel.
On 21/09/2020 12:38, Julien Grall wrote:
Hi all,
I have started to look at the deferral code (see
vcpu_start_shutdown_deferral()) because we need it for Liv
On 10.09.2020 15:35, Roger Pau Monne wrote:
> arch_init_memory will treat all the gaps on the physical memory map
> between RAM regions as MMIO and use share_xen_page_with_guest in order
> to assign them to dom_io. This has the side effect of setting the Xen
> heap flag on such pages, and thus is_s
On 21.09.20 16:29, Jan Beulich wrote:
Hi
On 21.09.2020 14:47, Oleksandr wrote:
On 21.09.20 15:31, Jan Beulich wrote:
On 21.09.2020 14:22, Oleksandr wrote:
On 14.09.20 16:52, Jan Beulich wrote:
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
@@ -1215,8 +1233,7 @@ void hvm_destroy_all_ior
flight 154556 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154556/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 154521 pass in
154556
test-amd64-i386-xl-qemuu-d
On 21.09.2020 16:43, Oleksandr wrote:
> On 21.09.20 16:29, Jan Beulich wrote:
>> On 21.09.2020 14:47, Oleksandr wrote:
>>> On 21.09.20 15:31, Jan Beulich wrote:
On 21.09.2020 14:22, Oleksandr wrote:
> On 14.09.20 16:52, Jan Beulich wrote:
>> On 10.09.2020 22:21, Oleksandr Tyshchenko wr
> -Original Message-
> From: Julien Grall
> Sent: 30 July 2020 19:18
> To: xen-devel@lists.xenproject.org
> Cc: jul...@xen.org; Julien Grall ; Stefano Stabellini
> ;
> Volodymyr Babchuk ; Andrew Cooper
> ; George
> Dunlap ; Ian Jackson ;
> Jan Beulich
> ; Wei Liu ; Roger Pau Monné
> ;
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
>>> between RAM regions as MMIO and use share_xen_page_with_guest in orde
MFENCE is overly heavyweight for SMP semantics on WB memory, because it also
orders weaker cached writes, and flushes the WC buffers.
This technique was used as an optimisation in Java[1], and later adopted by
Linux[2] where it was measured to have a 60% performance improvement in VirtIO
benchmark
On Fri, Sep 18, 2020 at 06:37:19PM +0200, Christoph Hellwig wrote:
> There is no obvious reason why zsmalloc needs to pre-fault the PTEs
> given that it later uses map_kernel_range to just like vmap().
IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
zs_map_object API runs under n
flight 154559 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154559/
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-
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 clearer this is PV only, add a check at the beginning of the
implementation. Take the opportunity to
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.
At the same time rework a comment in Arm code that does not make sense.
Signed-off-by: Julien Grall
---
Changes in v4:
- Remove acks
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 limited on Arm today. There
are only 2 callers in the common code:
- memory_exchange: Arm cannot not
From: Julien Grall
At the moment, Arm is providing a dummy implementation for the M2P
helpers used in common code. However, they are quite isolated and could
be used by other architecture in the future. So move all the helpers in
xen/mm.h.
Signed-off-by: Julien Grall
---
Changes in v4:
From: Julien Grall
Hi all,
Arm never supported a M2P yet there are some helpers implemented to deal with
the common code. However, the implementation of mfn_to_gmfn is completely
bogus.
This series aims to properly disable the M2P on Arm. See patch #2 for the
rationale regarding the lack of M2P
Hi Jan,
On 25/08/2020 08:40, Jan Beulich wrote:
On 24.08.2020 20:15, Andrew Cooper wrote:
I'm pretty sure the mfn_to_gmfn() stub is bogus before and after this change.
The two uses in common code are getdomaininfo and in memory_exchange(), which
result in junk.
It's been a long time back that
On Mon, Sep 21, 2020 at 10:42:56AM -0700, Minchan Kim wrote:
> IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
> zs_map_object API runs under non-preemtible section.
Make sense.
> > - area->vm = alloc_vm_area(PAGE_SIZE * 2, NULL);
> > + area->vm = get_vm_area(PAGE_SIZE * 2,
On Mon, Sep 21, 2020 at 08:17:08PM +0200, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 10:42:56AM -0700, Minchan Kim wrote:
> > IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
> > zs_map_object API runs under non-preemtible section.
>
> Make sense.
>
> > > - area->vm = all
On Mon, Sep 21, 2020 at 11:42:29AM -0700, Minchan Kim wrote:
> It seems zsmalloc is only customer the function so let's have the helper
> when we see another customer.
>
> If we don't have objection, I'd like to ask to Andrew fold this up.
Fine with me.
flight 154566 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154566/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 152631
test-amd64-i386-x
On 14.09.20 17:17, Jan Beulich wrote:
Hi Jan
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
---
MAINTAINERS |8 +-
xen/arch/x86/Kconfig|1 +
xen/arch/x86/hvm/dm.c |2 +-
xen/arch/x86/hvm/emulate.c |2 +-
xen/arch/x86/hvm/
On Fri, Sep 18, 2020 at 06:37:21PM +0200, Christoph Hellwig wrote:
> void shmem_unpin_map(struct file *file, void *ptr)
> {
> + long i = shmem_npages(file);
> +
> mapping_clear_unevictable(file->f_mapping);
> - __shmem_unpin_map(file, ptr, shmem_npte(file));
> + vunmap(ptr);
> +
flight 154581 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154581/
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 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
> > between RAM regions as MMIO and use share_xen_page_with_guest in order
> > to assign them to dom_io. This has the si
On 9/18/20 12:37 PM, Christoph Hellwig wrote:
>
> +static int gnttab_apply(pte_t *pte, unsigned long addr, void *data)
> +{
> + pte_t ***p = data;
> +
> + **p = pte;
> + (*p)++;
> + return 0;
> +}
> +
> static int arch_gnttab_valloc(struct gnttab_vm_area *area, unsigned
> nr_f
On 9/21/20 11:23 AM, 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 file:
flight 154576 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154576/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle 7 xen-boot fail REGR. vs. 154556
test-amd64-amd64-e
On Mon, 21 Sep 2020, Bertrand Marquis wrote:
> > On 18 Sep 2020, at 18:11, Julien Grall wrote:
> >
> > From: Julien Grall
> >
> > At the moment, Xen will stop processing the Device Tree if a memory
> > bank is empty (size == 0).
> >
> > Unfortunately, some of the Device Tree (such as on Colibr
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 clearer this is PV only, add a check at the beg
On Sat, 19 Sep 2020, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Mark Renesas IPMMU-VMSA as "Supported, not security supported"
> and remove dependencies on CONFIG_EXPERT.
>
> We can't treat the IOMMU driver as "Supported" since the device
> passthrough feature is not security s
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 limited on Arm today. There
> are only 2 callers in t
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 the domain shared
info path, but without a h
On 21/09/2020 19:02, Julien Grall wrote:
> diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
> index 4536a62940a1..15bb0aa30d22 100644
> --- 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)
> }
>
flight 154582 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154582/
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-
flight 154583 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154583/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 152631
test-amd64-i386-x
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~ ^
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 that called put_page().
Note that we don't ne
On 22.09.20 08:07, Nathan Chancellor wrote:
> Clang warns:
>
> kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
> than '|'; '|' will be evaluated first
> [-Wbitwise-conditional-parentheses]
> new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL :
> 0);
>
On 21/09/20 18:23, 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 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 definitions.
>>> + *
>>> + *
On 22.09.20 08:27, Paolo Bonzini wrote:
> On 21/09/20 18:23, 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 fil
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).
>
> aqomic_*, lol :)
Actually qatomic_ would be a go
79 matches
Mail list logo
