flight 154349 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154349/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-coresched-amd64-xl broken
test-amd64-amd64-xl-xsm
Andy has reported a libxenguest related build failure of qemu when
building qemu outside the Xen build environment. Problem is xenguest.h
now including xenctrl_dom.h, which is including xen/libelf/libelf.h.
The underlying problem is that libxenguest is basically offering some
"official" functions
On Tue, Sep 08, 2020 at 10:10:06PM +0200, David Hildenbrand wrote:
>Let's make sure splitting a resource on memory hotunplug will never fail.
>This will become more relevant once we merge selected System RAM
>resources - then, we'll trigger that case more often on memory hotunplug.
>
>In general, t
On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote:
>IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
>always set to 0 by hardware. This is far from beautiful (and confusing),
>and the bit only applies to SYSRAM. So let's move it out of the
>bus-specific (PnP)
On Tue, Sep 08, 2020 at 10:10:06PM +0200, David Hildenbrand wrote:
>Let's make sure splitting a resource on memory hotunplug will never fail.
>This will become more relevant once we merge selected System RAM
>resources - then, we'll trigger that case more often on memory hotunplug.
>
>In general, t
On Fri, Sep 11, 2020 at 12:34:56PM +0200, David Hildenbrand wrote:
>Some add_memory*() users add memory in small, contiguous memory blocks.
>Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
>
>This can quickly result in a lot of memory resources, whereby the actual
>resource bound
> From: Andrew Cooper
> Sent: Wednesday, September 9, 2020 5:59 PM
>
> They are currently named after the FSGSBASE instructions, but are not thin
> wrappers around said instructions, and therefore do not accurately reflect
> the
> logic they perform, especially when it comes to functioning safely
> From: Roger Pau Monne
> Sent: Monday, September 7, 2020 6:32 PM
>
> Linux PV guests will attempt to read the FEATURE_CONTROL MSR, so move
> the handling done in VMX code into guest_rdmsr as it can be shared
> between PV and HVM guests that way.
>
> Note that there's a slight behavior change an
> From: Jan Beulich
> Sent: Thursday, August 27, 2020 3:09 PM
>
> Doing this just in hvm_emulate_one_insn() is not enough.
> hvm_ud_intercept() and hvm_emulate_one_vm_event() can get invoked for
> insns requiring one or more continuations, and at least in principle
> hvm_emulate_one_mmio() could,
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-raw
testid guest-start
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.or
On Fri, 11 Sep 2020, Julien Grall wrote:
> Hi Bertrand,
>
> On 11/09/2020 14:56, Bertrand Marquis wrote:
> >
> >
> > > On 11 Sep 2020, at 14:51, Julien Grall wrote:
> > >
> > > Hi Bertrand,
> > >
> > > On 11/09/2020 14:32, Bertrand Marquis wrote:
> > > > > On 11 Sep 2020, at 14:11, Jan Beulic
On Fri, 11 Sep 2020, Julien Grall wrote:
> On 11/09/2020 14:11, Jan Beulich wrote:
> > All,
> >
> > the releases are about due, but will of course want to wait for the
> > XSA fixes going public on the 22nd. Please point out backports
> > you find missing from the respective staging branches, but
On 9/14/20 5:47 PM, Anchal Agarwal wrote:
> On Sun, Sep 13, 2020 at 11:43:30AM -0400, boris.ostrov...@oracle.com 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 Fri, 11 Sep 2020, Julien Grall wrote:
> From: Julien Grall
>
> The IOREQ code is using cmpxchg() with 64-bit value. At the moment, this
> is x86 code, but there is plan to make it common.
>
> To cater 32-bit arch, introduce two new helpers to deal with 64-bit
> cmpxchg().
>
> The Arm 32-bit
On Fri, 11 Sep 2020, Julien Grall wrote:
> From: Julien Grall
>
> The current set of helpers are quite confusing to follow as the naming
> is not very consistent.
>
> Given that cmpxchg_local() is not used in Xen, drop it completely.
> Furthermore, adopt a naming with _mb so all names are now co
flight 154336 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154336/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-qem
On Mon, Sep 14, 2020 at 02:38:49PM +0200, Jan Beulich wrote:
> While there's little point in enabling both, the combination ought to at
> least build correctly. Drop the direct PV_SHIM_EXCLUSIVE conditionals
> and instead zap PG_log_dirty to zero under the right conditions, and key
> other #ifdef-s
On Mon, Sep 14, 2020 at 05:26:57PM +0200, Jan Beulich wrote:
> On 14.09.2020 17:16, Roger Pau Monné wrote:
> > On Mon, Aug 24, 2020 at 02:08:11PM +0200, Jan Beulich wrote:
> >> Address at least the primary reason why 52bba67f8b87 ("efi/boot: Don't
> >> free ebmalloc area at all") was put in place:
From: Oleksandr Tyshchenko
And remove dependencies on CONFIG_EXPERT.
Signed-off-by: Oleksandr Tyshchenko
---
SUPPORT.md | 2 +-
xen/arch/arm/platforms/Kconfig | 2 +-
xen/drivers/passthrough/Kconfig | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/SU
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 to apply a user defined max_maptrack_frames value
> to dm_config in the same
On Sun, Sep 13, 2020 at 01:12:39PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Sep 10, 2020 at 12:58:57PM +0200, Marek Marczykowski-Górecki wrote:
> > On Thu, Sep 10, 2020 at 12:41:04PM +0200, Roger Pau Monné wrote:
> > > Adding toolstack maintainers.
> > >
> > > On Thu, Sep 10, 2020 at 12:
On Mon, Aug 24, 2020 at 02:08:11PM +0200, Jan Beulich wrote:
> Address at least the primary reason why 52bba67f8b87 ("efi/boot: Don't
> free ebmalloc area at all") was put in place: Make xen_in_range() aware
> of the freed range. This is in particular relevant for EFI-enabled
> builds not actually
On 10/09/2020 15:47, Jan Beulich wrote:
> On 09.09.2020 11:59, Andrew Cooper wrote:
>> To match the read side which is already split out. A future change will want
>> to use them.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
> Acked-by: Jan Beulich
> Of course ...
>
>> --- a/xe
On 14/09/2020 09:43, Jan Beulich wrote:
> On 11.09.2020 21:06, Andrew Cooper wrote:
>> It is conceptually wrong for this information to exist in the hypervisor in
>> the first place. Only the toolstack is capable of correctly reasoning about
>> the non-migrateability of guests.
> But isn't it the
flight 154341 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154341/
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
Am 14.09.20 um 17:05 schrieb Thomas Zimmermann:
Hi
Am 13.08.20 um 12:22 schrieb Christian König:
Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instan
Qemu requires a bleeding edge version of Python, not found in the current
travis environment. Skip building Qemu in that case.
Signed-off-by: Andrew Cooper
---
CC: Doug Goldstein
CC: Wei Liu
---
scripts/travis-build | 5 +
1 file changed, 5 insertions(+)
diff --git a/scripts/travis-build
On Monday, September 14, 2020 10:55 AM, Jan Beulich wrote:
> On 14.09.2020 16:46, Trammell Hudson wrote:
> > Option 3 would be to write wrappers for the few functions that are
> > used in the EFI boot path that cast-away the constness of their
> > arguments (while also silently cursing the UEFI fo
Hi Jan,
On 14/09/2020 16:16, Jan Beulich wrote:
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 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_args {
> +domid_t domid;
> +unsigne
flight 154333 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154333/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1b461403ee723dab01d5828714cca0b9396a6b3c
baseline version:
ovmf 067503a8c675ddd38b099
On Mon, Sep 14, 2020 at 02:23:55PM +0100, Andrew Cooper wrote:
> Qemu requires a bleeding edge version of Python, not found in the current
> travis environment. Skip building Qemu in that case.
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
On Mon, Sep 14, 2020 at 05:19:56PM +0200, Roger Pau Monné wrote:
> On Sun, Sep 13, 2020 at 01:12:39PM +0200, Marek Marczykowski-Górecki wrote:
> > Ok, The crash reported initially was caused by a different thing: using
> > seabios.bin instead of seabios-256k.bin (should that really cause the
> > cr
On 14.09.2020 17:16, Roger Pau Monné wrote:
> On Mon, Aug 24, 2020 at 02:08:11PM +0200, Jan Beulich wrote:
>> Address at least the primary reason why 52bba67f8b87 ("efi/boot: Don't
>> free ebmalloc area at all") was put in place: Make xen_in_range() aware
>> of the freed range. This is in particula
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 hvm_ioreq_vcpu {
> +struct
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_
prefix by ioreq_.
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();
> +return ioreq_handle_complet
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 to apply a user defined max_maptrack_frames value
to dm_config in the same way as for max_grant_frames?
Signed-off-by: Dmitry
Hi
Am 13.08.20 um 12:22 schrieb Christian König:
> Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
>> GEM object functions deprecate several similar callback interfaces in
>> struct drm_driver. This patch replaces the per-driver callbacks with
>> per-instance callbacks in amdgpu. The only exceptio
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);
> }
>
> +static inline bool hvm_ioreq_ne
On 14.09.2020 16:46, Trammell Hudson wrote:
> On Monday, September 14, 2020 10:30 AM, Jan Beulich wrote:
>> On 14.09.2020 16:25, Trammell Hudson wrote:
>>> By defining IN as const, the EFI handler functions become almost
>>> const-correct and allow most of the rest of the EFI boot code to
>>> use
On Monday, September 14, 2020 10:30 AM, Jan Beulich wrote:
> On 14.09.2020 16:25, Trammell Hudson wrote:
> > By defining IN as const, the EFI handler functions become almost
> > const-correct and allow most of the rest of the EFI boot code to
> > use constant strings.
>
> How does this work with c
On 14.09.2020 16:04, Andrew Cooper wrote:
> On 14/09/2020 09:43, Jan Beulich wrote:
>> On 11.09.2020 21:06, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -708,7 +708,8 @@ int init_domain_cpuid_policy(struct domain *d)
>>> if ( !p )
>>> retur
On Tue, Sep 08, 2020 at 02:19:03PM +, Wei Liu wrote:
> On Thu, Sep 03, 2020 at 11:05:37AM +0100, Paul Durrant wrote:
> > From: Paul Durrant
> >
> > The manpage for 'xl' documents that guest co-operation is required for a
> > (non-
> > forced) block-detach operation and that it may consequent
On 14.09.2020 16:25, Trammell Hudson wrote:
> By defining IN as const, the EFI handler functions become almost
> const-correct and allow most of the rest of the EFI boot code to
> use constant strings.
How does this work with combined "IN OUT"? I'm afraid there is a
reason why things aren't done t
By defining IN as const, the EFI handler functions become almost
const-correct and allow most of the rest of the EFI boot code to
use constant strings.
There are a few places in the code that casts away the const
that should be reconsidered. The config parser code modifies the
config file in place
On Mon, Sep 07, 2020 at 03:00:27PM -0400, Trammell Hudson wrote:
> From: Trammell hudson
>
> If secure boot is enabled, the Xen command line arguments are ignored.
> If a unified Xen image is used, then the bundled configuration, dom0
> kernel, and initrd are prefered over the ones listed in the
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/hvm.c |2 +-
> xen/arch/x86/hvm/
On Mon, Sep 07, 2020 at 03:00:26PM -0400, Trammell Hudson wrote:
> From: Trammell hudson
>
> 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" E
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 a code movement.
>
> This support is goin
flight 154332 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154332/
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
flight 154324 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154324/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-qem
> On Sep 11, 2020, at 5:50 PM, Stefano Stabellini
> wrote:
>
> On Fri, 11 Sep 2020, George Dunlap wrote:
>> The Code of Conduct has been approved [1]; now we need to find it a
>> home. Since we've started using sphinx for the hypervisor documents,
>> I propose doing the same for the project-
On 11.09.2020 16:43, Sergey Temerkhanov wrote:
> @@ -1510,6 +1517,24 @@ void __init efi_init_memory(void)
> desc->PhysicalStart, desc->PhysicalStart + len - 1,
> desc->Type, desc->Attribute);
>
> +/*
> + * EfiRuntimeServicesCode and EfiRuntimeServic
It is only available in make 4.0 and later, and not for example in CentOS 7.
Rewrite the logic to use echo and shell redirection, using a single capture
group to avoid having 12 different processes in quick succession each
appending one line to the file.
Fixes: 52dbd6f07cea7a ("tools: generate pk
As demonstrated by Gitlab CI.
Still pending is the xenstat fix, and a newly discovered randconfig issue.
Andrew Cooper (2):
tools/libs/vchan: Don't run the headers check
tools/Makefile: Drop the use of $(file ...)
tools/Rules.mk| 52 +-
There was never a headers check previously, and CentOS 6 can't cope with the
anonymous union in struct libxenvchan.
cc1: warnings being treated as errors
... tools/include/libxenvchan.h:75: error: declaration does not declare
anything
make[6]: *** [headers.chk] Error 1
Fixes: 8ab2429f12 ("
On 11.09.2020 10:20, Paul Durrant wrote:
> From: Paul Durrant
>
> At the moment iommu_map() and iommu_unmap() take a page order rather than a
> count, whereas iommu_iotlb_flush() takes a page count rather than an order.
> This patch makes them consistent with each other, opting for a page count
Thanks! Being picky you likely wan to split this into two separate
commits: one for adding need_to_free and the other for
display_file_info. There's no relation between the two that would
require them to be on the same commit.
On Mon, Sep 07, 2020 at 03:00:25PM -0400, Trammell Hudson wrote:
> Fro
While there's little point in enabling both, the combination ought to at
least build correctly. Drop the direct PV_SHIM_EXCLUSIVE conditionals
and instead zap PG_log_dirty to zero under the right conditions, and key
other #ifdef-s off of that.
While there also expand on ded576ce07e9 ("x86/shadow:
This combination doesn't really make sense (and there likely are more).
The alternative here would be some presumably intrusive #ifdef-ary to
get this combination to actually build again.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -23,7 +23,7 @@ config X8
Just like HVM, defaulting SHADOW_PAGING and TBOOT to Yes in shim-
exclusive mode makes no sense, as the respective code is dead there.
Also adjust the shim default config file: It needs to specifiy values
only for settings where a non-default value is wanted.
Signed-off-by: Jan Beulich
--- a/xe
The first change is simply addressing a build issue noticed by
Andrew. The build breakage goes beyond this specific combination
though - PV_SHIM_EXCLUSIVE plus HVM is similarly an issue. This
is what the last patch tries to take care of, in a shape already
on irc noticed to be controversial. I'm su
> -Original Message-
> From: Julien Grall
> Sent: 14 September 2020 11:47
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini
> ; Jun Nakajima ; Kevi
On Mon, Sep 14, 2020 at 12:41:09PM +0200, Roger Pau Monné wrote:
> On Tue, Sep 08, 2020 at 02:19:03PM +, Wei Liu wrote:
> > On Thu, Sep 03, 2020 at 11:05:37AM +0100, Paul Durrant wrote:
> > > From: Paul Durrant
> > >
> > > The manpage for 'xl' documents that guest co-operation is required for
On 14.09.2020 13:36, Trammell Hudson wrote:
> On Monday, September 14, 2020 6:24 AM, Roger Pau Monné
> wrote:
>> On Mon, Sep 07, 2020 at 03:00:27PM -0400, Trammell Hudson wrote:
>> [...]
>>> - static const __initconst EFI_GUID global_guid = EFI_GLOBAL_VARIABLE;
>>> - uint8_t secboot, setupmod
On 14.09.2020 13:19, Trammell Hudson wrote:
> On Monday, September 14, 2020 6:06 AM, Roger Pau Monné
> wrote:
>> On Mon, Sep 07, 2020 at 03:00:26PM -0400, Trammell Hudson wrote:
>>> - file->ptr = (void *)pe_find_section(image->ImageBase, image->ImageSize,
>>
>> This already returns a void *, so
The config file, kernel, initrd, etc should only be freed if they
are allocated with the UEFI allocator.
Signed-off-by: Trammell Hudson
---
xen/common/efi/boot.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 402
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
If secure boot is enabled, the Xen command line arguments are ignored.
If a unified Xen image is used, then the bundled configuration, dom0
kernel, and initrd are prefered over the ones listed in the config file.
Unlike the shim based verification, the PE signature on a unified image
covers the al
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
---
xen/common/efi/boot.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/xen/common/efi/bo
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
On Monday, September 14, 2020 6:24 AM, Roger Pau Monné
wrote:
> On Mon, Sep 07, 2020 at 03:00:27PM -0400, Trammell Hudson wrote:
> [...]
> > - static const __initconst EFI_GUID global_guid = EFI_GLOBAL_VARIABLE;
> > - uint8_t secboot, setupmode;
> > - UINTN secboot_size = sizeof(secboot);
>
On Monday, September 14, 2020 6:06 AM, Roger Pau Monné
wrote:
> On Mon, Sep 07, 2020 at 03:00:26PM -0400, Trammell Hudson wrote:
> > [...]
> > It is inspired by systemd-boot's unified kernel technique and borrows the
> > function to locate PE sections from systemd's LGPL'ed code. During EFI
> > b
> On 12 Sep 2020, at 14:08, Juergen Gross wrote:
>
> Making getBridge() static triggered a build error with some gcc versions:
>
> error: 'strncpy' output may be truncated copying 15 bytes from a string of
> length 255 [-Werror=stringop-truncation]
>
> Fix that by using a buffer with 256 byt
Hi Paul,
I am sorry for jumping very late in the discussion.
On 11/09/2020 09:20, Paul Durrant wrote:
From: Paul Durrant
The 'legacy' functions do implicit flushing so amend the callers to do the
appropriate flushing.
Unfortunately, because of the structure of the P2M code, we cannot remove
On Monday, September 14, 2020 5:05 AM, Roger Pau Monné
wrote:
> Thanks! Being picky you likely wan to split this into two separate
> commits: one for adding need_to_free and the other for
> display_file_info. There's no relation between the two that would
> require them to be on the same commit.
Hi Paul,
On 11/09/2020 09:20, Paul Durrant wrote:
From: Paul Durrant
At the moment iommu_map() and iommu_unmap() take a page order rather than a
count, whereas iommu_iotlb_flush() takes a page count rather than an order.
This patch makes them consistent with each other, opting for a page count
Build this code into an archive, to parallel bsearch().
Signed-off-by: Jan Beulich
---
xen/common/Makefile| 1 -
xen/lib/Makefile | 1 +
xen/{common => lib}/sort.c | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename xen/{common => lib}/sort.c (100%)
diff --git a/xen/co
... into its own CU, for being unrelated to other things in
common/lib.c. For now it gets compiled into built_in.o rather than
lib.a, as it gets used unconditionally by Arm's as well as x86'es
{,__}start_xen(). But this could be changed in principle, the more that
there typically aren't any constru
Build this code into an archive, which results in not linking it into
x86 final binaries. This saves a little bit of dead code.
Signed-off-by: Jan Beulich
---
xen/common/Makefile | 1 -
xen/lib/Makefile | 1 +
xen/{common => lib}/bsearch.c | 0
3 files changed, 1 insertion
Build this code into an archive, which results in not linking it into
x86 final binaries. This saves about 1.5k of dead code.
While moving the source file, take the opportunity and drop the
pointless EXPORT_SYMBOL().
Signed-off-by: Jan Beulich
---
xen/common/Makefile | 1 -
xen/lib/Mak
Build the source file always, as by putting it into an archive it still
won't be linked into final binaries when not needed. This way possible
build breakage will be easier to notice, and it's more consistent with
us unconditionally building other library kind of code (e.g. sort() or
bsearch()).
W
In order to (subsequently) drop odd things like CONFIG_NEEDS_LIST_SORT
just to avoid bloating binaries when only some arch-es and/or
configurations need generic library routines, combine objects under lib/
into an archive, which the linker then can pick the necessary objects
out of.
Note that we c
... into its own CU, to build it into an archive.
Signed-off-by: Jan Beulich
---
xen/common/lib.c | 39 --
xen/lib/Makefile | 1 +
xen/lib/parse-size.c | 50
3 files changed, 51 insertions(+), 39 deletions(-)
This is, besides for tidying, in preparation of then starting to use an
archive rather than an object file for generic library code which
arch-es (or even specific configurations within a single arch) may or
may not need.
Signed-off-by: Jan Beulich
---
xen/Makefile | 3 ++-
xen/Rules.mk
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 - judging from the observed
behavior on x86 - un
In a few cases we link in library-like functions when they're not
actually needed. While we could use Kconfig options for each one
of them, I think the better approach for such generic code is to
build it always (thus making sure a build issue can't be introduced
for these in any however exotic con
On Mon, Sep 14, 2020 at 09:39:01AM +, Wei Liu wrote:
> On Thu, Sep 10, 2020 at 05:42:10PM +0200, Juergen Gross wrote:
> > When renaming the libxenguest sources to xg_*.c there was an omission
> > in the Makefile when setting the zlib related define for the related
> > sources. Fix that.
> >
>
Hi Jan,
On 14/09/2020 10:03, Jan Beulich wrote:
On 11.09.2020 18:33, Julien Grall wrote:
At the moment, Xen doesn't have a formal memory model. Instead, we are
relying on intuitions. This can lead to heated discussion on what can a
processor/compiler do or not.
We also have some helpers that n
On Mon, Sep 14, 2020 at 11:38:19AM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Sep 14, 2020 at 09:35:42AM +, Wei Liu wrote:
> > On Sat, Sep 12, 2020 at 03:58:07PM +0200, Juergen Gross wrote:
> > > Commit 7c273ffdd0e91 ("tools/python: drop libxenguest from setup.py")
> > > was just wrong:
On Thu, Sep 10, 2020 at 05:42:10PM +0200, Juergen Gross wrote:
> When renaming the libxenguest sources to xg_*.c there was an omission
> in the Makefile when setting the zlib related define for the related
> sources. Fix that.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
On Mon, Sep 14, 2020 at 09:35:42AM +, Wei Liu wrote:
> On Sat, Sep 12, 2020 at 03:58:07PM +0200, Juergen Gross wrote:
> > Commit 7c273ffdd0e91 ("tools/python: drop libxenguest from setup.py")
> > was just wrong: there is one function from libxenguest used in the
> > bindings, so readd the libra
On Sat, Sep 12, 2020 at 10:49:13AM +0200, Juergen Gross wrote:
> Using $(file ...) breaks the build with make older than version 4.0.
> Replace it with echo.
>
> Fixes: 52dbd6f07cea7a ("tools: generate pkg-config files from make variables")
> Signed-off-by: Juergen Gross
This patch is superseded
On Sat, Sep 12, 2020 at 03:58:07PM +0200, Juergen Gross wrote:
> Commit 7c273ffdd0e91 ("tools/python: drop libxenguest from setup.py")
> was just wrong: there is one function from libxenguest used in the
> bindings, so readd the library again.
>
> While at it remove the unused PATH_LIBXL setting.
On Sat, Sep 12, 2020 at 03:08:36PM +0200, Juergen Gross wrote:
> Making getBridge() static triggered a build error with some gcc versions:
>
> error: 'strncpy' output may be truncated copying 15 bytes from a string of
> length 255 [-Werror=stringop-truncation]
>
> Fix that by using a buffer with
On Mon, Sep 14, 2020 at 10:24:20AM +0100, Andrew Cooper wrote:
> It is only available in make 4.0 and later, and not for example in CentOS 7.
>
> Rewrite the logic to use echo and shell redirection, using a single capture
> group to avoid having 12 different processes in quick succession each
> ap
On Mon, Sep 14, 2020 at 10:24:19AM +0100, Andrew Cooper wrote:
> There was never a headers check previously, and CentOS 6 can't cope with the
> anonymous union in struct libxenvchan.
>
> cc1: warnings being treated as errors
> ... tools/include/libxenvchan.h:75: error: declaration does not dec
On 14.09.2020 11:14, Trammell Hudson wrote:
> On Tuesday, September 8, 2020 8:29 AM, Jan Beulich wrote:
>> [...] As with, I think, the majority of new
>> features, distros would pick up your new functionality mainly for
>> use in new versions, and hence would likely run with new binutils
>> anyway
On Tuesday, September 8, 2020 8:29 AM, Jan Beulich wrote:
> [...] As with, I think, the majority of new
> features, distros would pick up your new functionality mainly for
> use in new versions, and hence would likely run with new binutils
> anyway by that time.
It also occurs to me that the binu
1 - 100 of 107 matches
Mail list logo
