On 20.11.2020 18:44, Julien Grall wrote:
> Hi Jan,
>
> On 20/11/2020 16:03, Jan Beulich wrote:
>> On 23.10.2020 17:41, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
>>> while the __acpi_os_{un,}map_memory() are meant to be
flight 156958 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156958/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
flight 156953 qemu-mainline real [real]
flight 156960 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156953/
http://logs.test-lab.xenproject.org/osstest/logs/156960/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Fri, Nov 20, 2020 at 09:54:42AM +0100, Jan Beulich wrote:
> On 20.11.2020 09:28, Roger Pau Monné wrote:
> > On Fri, Nov 20, 2020 at 09:09:51AM +0100, Jan Beulich wrote:
> >> On 19.11.2020 18:57, Manuel Bouyer wrote:
> >>> I added an ASSERT() after the printf to ket a stack trace, and got:
> >>>
On Fri, Nov 20, 2020 at 11:38:24AM +0100, Manuel Bouyer wrote:
> On Fri, Nov 20, 2020 at 11:00:05AM +0100, Jan Beulich wrote:
> > On 20.11.2020 10:27, Manuel Bouyer wrote:
> > > On Fri, Nov 20, 2020 at 09:59:57AM +0100, Jan Beulich wrote:
> > >> Well, anything coming through the LAPIC needs ack-ing
On Fri, Nov 20, 2020 at 12:32:58PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
>
flight 156955 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156955/
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-install fail REGR. vs. 152332
test-amd64-i386-xl-
On Mon, Nov 23, 2020 at 10:57:13AM +0100, Roger Pau Monné wrote:
> > [...]
> > OK.
> > I finally found where the EOI occurs (it's within a macro so s simple grep
> > didn't show it).
> >
> > When interrupts are not masked (e.g. via cli), the ioapic halder is called.
> > From here, 2 paths can happ
Forever since its introduction this has been using an inverted relation
operator.
Fixes: 54057a28f22b ("x86: support SMBIOS v3")
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/dmi_scan.c
+++ b/xen/arch/x86/dmi_scan.c
@@ -357,7 +357,7 @@ static int __init dmi_iterate(void (*dec
Hello ,
> On 22 Nov 2020, at 10:55 pm, Leo Krueger wrote:
>
> Hi Julien,
>
> finally I could try out what you suggested, please find my answers inline.
>
>> -Ursprüngliche Nachricht-
>> Von: Julien Grall
>> Gesendet: Mittwoch, 18. November 2020 13:24
>> An: Stefano Stabellini ; Leo Kr
On 23/11/2020 11:33, Jan Beulich wrote:
> Forever since its introduction this has been using an inverted relation
> operator.
>
> Fixes: 54057a28f22b ("x86: support SMBIOS v3")
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On Wed, Nov 04, 2020 at 08:56:50AM +0100, Jan Beulich wrote:
> When a page table page gets de-validated, its type reference count drops
> to zero (and PGT_validated gets cleared), but its type remains intact.
> XEN_DOMCTL_getpageframeinfo3, therefore, so far reported prior usage for
> such pages. A
Hello Jan,
> On 20 Nov 2020, at 12:14 am, Stefano Stabellini
> wrote:
>
> On Thu, 19 Nov 2020, Julien Grall wrote:
>> On Thu, 19 Nov 2020, 23:38 Stefano Stabellini,
>> wrote:
>> On Thu, 19 Nov 2020, Rahul Singh wrote:
On 19/11/2020 09:53, Jan Beulich wrote:
> On 19.11.2020 10:21
On Fri, Nov 20, 2020 at 01:45:19PM +0100, Jan Beulich wrote:
> ACPI mandates use of E820 (or newer, e.g. EFI), and in fact firmware
> has been observed to include E820_ACPI ranges in what E801 reports as
> available (really "configured") memory.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau
On 20/11/2020 12:48, Jan Beulich wrote:
> On 04.11.2020 08:56, Jan Beulich wrote:
>> When a page table page gets de-validated, its type reference count drops
>> to zero (and PGT_validated gets cleared), but its type remains intact.
>> XEN_DOMCTL_getpageframeinfo3, therefore, so far reported prior u
On 23.11.2020 12:48, Roger Pau Monné wrote:
> On Wed, Nov 04, 2020 at 08:56:50AM +0100, Jan Beulich wrote:
>> When a page table page gets de-validated, its type reference count drops
>> to zero (and PGT_validated gets cleared), but its type remains intact.
>> XEN_DOMCTL_getpageframeinfo3, therefore
On 20/11/2020 12:45, Jan Beulich wrote:
> ACPI mandates use of E820 (or newer, e.g. EFI), and in fact firmware
> has been observed to include E820_ACPI ranges in what E801 reports as
> available (really "configured") memory.
>
> Signed-off-by: Jan Beulich
> ---
> TBD: Alternatively we could drop a
The first three patches fix fallout from the re-work of
acpi_os_{,un}map_memory(): Direct uses of __acpi_map_table() are now
no longer valid once we've reached SYS_STATE_boot. This was originally
noticed by system shutdown no longer working (patch 1), but clearly
extends beyond of this (patches 2 a
acpi_fadt_parse_sleep_info() runs when the system is already in
SYS_STATE_boot. Hence its direct call to __acpi_map_table() won't work
anymore. This call should probably have been replaced long ago already,
as the layering violation hasn't been necessary for quite some time.
Fixes: 1c4aa69ca1e1 ("
Use of __acpi_map_table() here was at least close to an abuse already
before, but it will now consistently return NULL here. Drop the layering
violation and use set_fixmap() directly. Re-use of the ACPI fixmap area
is hopefully going to remain "fine" for the time being.
Add checks to acpi_enter_sl
Use of __acpi_map_table() is kind of an abuse here, and doesn't work
anymore for the majority of cases if any of the tables lives outside the
low first Mb. Keep this (ab)use only prior to reaching SYS_STATE_boot,
primarily to avoid needing to audit whether any of the calls here can
happen this earl
We can be more tolerant as long as the data collected from FACS is only
needed to enter S3. A prior change already added suitable checking to
acpi_enter_sleep().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -420,22 +420,22 @@ acpi_fadt_parse_sleep_i
On 23.11.2020 13:26, Andrew Cooper wrote:
> On 20/11/2020 12:48, Jan Beulich wrote:
>> On 04.11.2020 08:56, Jan Beulich wrote:
>>> When a page table page gets de-validated, its type reference count drops
>>> to zero (and PGT_validated gets cleared), but its type remains intact.
>>> XEN_DOMCTL_getpa
On Mon, Nov 23, 2020 at 12:32:41PM +0100, Manuel Bouyer wrote:
> On Mon, Nov 23, 2020 at 10:57:13AM +0100, Roger Pau Monné wrote:
> > > [...]
> > > OK.
> > > I finally found where the EOI occurs (it's within a macro so s simple grep
> > > didn't show it).
> > >
> > > When interrupts are not masked
On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottoml
On 23.11.2020 13:37, Andrew Cooper wrote:
> On 20/11/2020 12:45, Jan Beulich wrote:
>> ACPI mandates use of E820 (or newer, e.g. EFI), and in fact firmware
>> has been observed to include E820_ACPI ranges in what E801 reports as
>> available (really "configured") memory.
>>
>> Signed-off-by: Jan Be
1: move PCI arrays next to the function using them
2: "com=" command line options are x86-specific
3: drop stray "#ifdef CONFIG_HAS_PCI"
Jan
Pure code motion; no functional change intended.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -153,312 +153,6 @@ struct ns16550_config_param {
unsigned int uart_offset;
unsigned int first_offset;
};
-
-/*
- * Create looku
Pure code motion (plus the addition of "#ifdef CONFIG_X86); no
functional change intended.
Reported-by: Julien Grall
Signed-off-by: Jan Beulich
---
v2: Re-base over new earlier patch.
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -318,8 +318,8 @@ Interrupts.
There's no point wrapping the function invocation when
- the function body is already suitably wrapped,
- the function itself is unconditionally available.
Reported-by: Julien Grall
Signed-off-by: Jan Beulich
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -662,9 +662,7 @@
Rahul,
On 23.11.2020 12:54, Rahul Singh wrote:
> Hello Jan,
as an aside - it helps if you also put the addressee of your mail
on the To list.
>> On 20 Nov 2020, at 12:14 am, Stefano Stabellini
>> wrote:
>>
>> On Thu, 19 Nov 2020, Julien Grall wrote:
>>> On Thu, 19 Nov 2020, 23:38 Stefano Stabe
On 29.10.2020 16:24, Bertrand Marquis wrote:
>> On 19 Oct 2020, at 08:21, Jan Beulich wrote:
>>
>> This again was working right only as long as $(LIBHEADER) consisted of
>> just one entry.
>>
>> Signed-off-by: Jan Beulich
> Reviewed-by: Bertrand Marquis
>
> The change is obviously fixing a bug
These are grouped into a series largely because of their origin,
not so much because there are heavy dependencies among them.
Compared to v2, there's a new patch resulting from review feedback,
and the last patch should be fully usable now. See also the
individual patches.
1: drop acquiring of per
The per-vCPU virq_lock, which is being held anyway, together with there
not being any call to evtchn_port_set_pending() when v->virq_to_evtchn[]
is zero, provide sufficient guarantees. Undo the lock addition done for
XSA-343 (commit e045199c7c9c "evtchn: address races with
evtchn_reset()"). Update
Use {read,write}_atomic() to exclude any eventualities, in particular
observing that accesses aren't all happening under a consistent lock.
Requested-by: Julien Grall
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -446,7 +446,7 @@ in
There's no need to serialize all sending of vIRQ-s; all that's needed
is serialization against the closing of the respective event channels
(so far by means of a barrier). To facilitate the conversion, switch to
an ordinary write locked region in evtchn_close().
Signed-off-by: Jan Beulich
---
v3:
Especially for the use in evtchn_move_pirqs() (called when moving a vCPU
across pCPU-s) and the ones in EOI handling in PCI pass-through code,
serializing perhaps an entire domain isn't helpful when no state (which
isn't e.g. further protected by the per-channel lock) changes.
Unfortunately this i
While there don't look to be any problems with this right now, the lock
order implications from holding the lock can be very difficult to follow
(and may be easy to violate unknowingly). The present callbacks don't
(and no such callback should) have any need for the lock to be held.
However, vm_ev
Parts of this were discussed in the context of Andrew's CET-SS work.
Further parts simply fit the underlying picture. And a few patches
towards the end get attached here simply because of their dependency.
What is now patch 7 has been moved to the end of the series, in the
hope of at least unblocki
Introduce proper assembler macros instead, enabled only when the
assembler itself doesn't support the insns. To avoid duplicating the
macros for assembly and C files, have them processed into asm-macros.h.
This in turn requires adding a multiple inclusion guard when generating
that header.
No chan
Use ALTERNATIVE directly, such that at the use sites it is visible that
alternative code patching is in use. Similarly avoid hiding the fact in
SAVE_ALL.
No change to generated code.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Further adjust comment in asm_domain_crash_synchro
There's little point in having two separate headers both getting
included by asm_defns.h. This in particular reduces the number of
instances of guarding asm(".include ...") suitably in such dual use
headers.
No change to generated code.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
-
On Fri, Nov 20, 2020 at 01:53:42PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 20, 2020 at 12:46:18PM +0100, Juergen Gross wrote:
> > 30 files changed, 325 insertions(+), 598 deletions(-)
>
> Much awesome ! I'll try and get that objtool thing sorted.
This seems to work for me. It isn't 100% accur
Under certain conditions CPUs can speculate into the instruction stream
past a RET instruction. Guard against this just like 3b7dab93f240
("x86/spec-ctrl: Protect against CALL/JMP straight-line speculation")
did - by inserting an "INT $3" insn. It's merely the mechanics of how to
achieve this that
There's no point having every replacement variant to also specify the
INT3 - just have it once in the base macro. When patching, NOPs will get
inserted, which are fine to speculate through (until reaching the INT3).
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
I also wonder whether t
Put insertion of INT3 behind CONFIG_SPECULATIVE_HARDEN_BRANCH
conditionals.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/indirect-thunk.S
+++ b/xen/arch/x86/indirect-thunk.S
@@ -11,8 +11,10 @@
#include
+#ifdef CONFIG_SPECULATIVE_HARDEN_BRANCH
/* Don't transform the "ret" fur
Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had
to introduce a number of #ifdef-s to make the build work with older tool
chains. Introduce an assembler macro covering for tool chains not
knowing of CET-SS, allowing some conditionals where just SETSSBSY is the
problem to be d
On 23.11.2020 14:42, Jan Beulich wrote:
> 1: replace __ASM_{CL,ST}AC
> 2: drop ASM_{CL,ST}AC
> 3: fold indirect_thunk_asm.h into asm-defns.h
> 4: guard against straight-line speculation past RET
> 5: limit amount of INT3 in IND_THUNK_*
> 6: make guarding against straight-line speculation optional
>
On 03.11.2020 11:54, Jan Beulich wrote:
> Especially the latter three patches provide only small possible
> gains, from all I can tell. I nevertheless wanted to put up the
> entire set for consideration.
>
> 1: consistently inline {,un}adjust_guest_le()
> 2: fold redundant calls to adjust_guest_le
On 04.11.2020 11:50, Jan Beulich wrote:
> On 03.11.2020 18:31, Andrew Cooper wrote:
>> On 03/11/2020 17:06, Jan Beulich wrote:
>>> Prior to 4.15 Linux, when running in PV mode, did not install a #GP
>>> handler early enough to cover for example the rdmsrl_safe() of
>>> MSR_K8_TSEG_ADDR in bsp_init_
On 06.11.2020 16:58, Wei Liu wrote:
> On Thu, Nov 05, 2020 at 04:56:53PM +0100, Jan Beulich wrote:
>> Using max undermines the separation between default and max. For example,
>> turning off AVX512F on an MPX-capable system silently turns on MPX,
>> despite this not being part of the default policy
On 06.11.2020 10:37, Jan Beulich wrote:
> When shattering a large page, we first construct the new page table page
> and only then hook it up. The "pre" hook in this case does nothing, for
> the page starting out all blank. Avoid 512 calls into shadow code in
> this case by passing in INVALID_GFN,
On Sun, Nov 22, 2020 at 11:54 PM Finn Thain wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.
Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation
On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches. Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about
While the sub-groups may seem somewhat unrelated, there are inter-
dependencies (logical, functional, or contextual). The majority of
the patches is new in v2; one previously standalone patch has been
integrated into here.
01: mm: check for truncation in vmalloc_type()
02: mm: introduce xvmalloc()
While it's currently implied from the checking xmalloc_array() does,
let's make this more explicit in the function itself. As a result both
involved local variables don't need to have size_t type anymore. This
brings them in line with the rest of the code in this file.
Requested-by: Julien Grall
All of the array allocations in grant_table_init() can exceed a page's
worth of memory, which xmalloc()-based interfaces aren't really suitable
for after boot. We also don't need any of these allocations to be
physically contiguous.. Introduce interfaces dynamically switching
between xmalloc() et a
This is in preparation for the area size exceeding a page's worth of
space, as will happen with AMX as well as Architectural LBR.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
vCPU-s get maximum size areas allocated initially. Hidden (and in
particular default-off) features may allow for a smaller size area to
suffice.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v2: Use 1ul instead of 1ull.
---
This could be further shrunk if we used XSAVEC / if we real
Instead of (just partially) open-coding it, re-use the function after
suitably moving it up.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -611,6 +611,34 @@ unsigned int xstate_ctxt_size(u64 xcr0)
return _xstate_ctxt_size(xcr0);
}
+sta
They're redundant with respective fields from the raw CPUID policy; no
need to keep two copies of the same data. This also breaks
recalculate_xstate()'s dependency on xstate_init(), allowing host CPUID
policy calculation to be moved together with that of the raw one (which
a subsequent change willl
XCNTXT_MASK is effectively embedded in recalculate_xstate(), and
xsave_cntxt_size was redundant with the host CPUID policy's
xstate.max_size field.
Use the host CPUID policy as input (requiring it to be calculated
earlier), thus allowing e.g. "cpuid=no-avx512f" to also result in
avoiding allocatio
On Mon, Nov 23, 2020 at 01:39:55PM +0100, Jan Beulich wrote:
> acpi_fadt_parse_sleep_info() runs when the system is already in
> SYS_STATE_boot. Hence its direct call to __acpi_map_table() won't work
> anymore. This call should probably have been replaced long ago already,
> as the layering violati
There's no point in including unsupported components in the size
calculations of xstate_{alloc,update}_save_area().
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -501,8 +501,12 @@ int xstate_alloc_save_area(struct vcpu *
unsigned int
This is in preparation for the buffer sizes exceeding a page's worth of
space, as will happen with AMX as well as Architectural LBR.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#inc
These being controlled by XCR0, enabling support is relatively
straightforward. Note however that there won't be any use of them until
their dependent ISA extension CPUID flags get exposed, not the least due
to the way recalculate_xstate() handles the dependencies in kind of a
reverse manner.
Sign
On Mon, Nov 23, 2020 at 01:51:12PM +0100, Roger Pau Monné wrote:
> Hm, yes, it's quite weird. Do you know whether a NetBSD kernel can be
> multibooted from pxelinux with Xen? I would like to see if I can
> reproduce this myself.
Yes, if Xen+linux can boot, Xen+netbsd should boot too.
In a previous
A maximum extended leaf input value with the high half different from
0x8000 should not be considered valid - all leaves should be cleared in
this case.
Signed-off-by: Jan Beulich
---
v2: Integrate into series.
--- a/tools/tests/cpu-policy/test-cpu-policy.c
+++ b/tools/tests/cpu-policy/test-cpu-
Zapping leaf data for out of range leaves is just one half of it: To
avoid guests (bogusly or worse) inferring information from mere leaf
presence, also shrink maximum indicators such that the respective
trailing entry is not all blank (unless of course it's the initial
subleaf of a leaf that's not
Break out this logic from calculate_host_policy() to also use it in the
x86 emulator harness, where subsequently we'll want to avoid open-coding
AMX maximum palette bounding.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-e
This requires bumping the number of basic leaves we support. Apart from
this the logic is modeled as closely as possible to that of leaf 7
handling.
The checks in x86_cpu_policies_are_compatible() may be more strict than
they ultimately need to be, but I'd rather start being on the safe side.
Sig
This will be used by AMX insns. Note that CR0.TS behavior is only
assumed to be similar to AVX* insns, as the ISA extensions document (as
of rev 041) doesn't specify this either way. But since XFD is not
supposed to be used for lazy context restore, it's unlikely to work any
other way.
Signed-off-
This is relatively straightforward, and hence best suited to introduce a
few other general pieces.
Testing of this will be added once a sensible test can be put together,
i.e. when support for other insns is also there.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/tools/tests/x86_emulator/pred
While ver 041 of the ISA extensions doc also specifies
xcr0_supports_palette() returning false as one of the #GP(0) reasons for
LDTILECFG, the earlier #UD conditions look to make this fully dead.
Signed-off-by: Jan Beulich
---
v2: New.
---
SDE: -spr
--- a/tools/tests/x86_emulator/predicates.c
++
Hi Jan.
As it was agreed, below the list of proposed renaming (naming) within
current series.
If there are no objections I will follow the proposed renaming. If any
please let me know.
1. Global (existing):
hvm_map_mem_type_to_ioreq_server -> ioreq_server_map_mem_type
hvm_select_ior
On 23.11.2020 15:39, Oleksandr wrote:
> As it was agreed, below the list of proposed renaming (naming) within
> current series.
Thanks for compiling this. A couple of suggestions for consideration:
> 1. Global (existing):
> hvm_map_mem_type_to_ioreq_server -> ioreq_server_map_mem_type
> hvm_
1: drop three unused variables
2: reduce casting involved in guest action retrieval
Jan
I didn't bother figuring which commit(s) should have deleted them while
removing their last uses.
Signed-off-by: Jan Beulich
---
v2: Yet one more.
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1402,7 +1402,6 @@ void desc_guest_eoi(struct irq_desc *des
{
irq_guest_action_t *action;
Introduce a helper function covering both the IRQ_GUEST check and the
cast involved in obtaining the (correctly typed) pointer. Where possible
add const and/or reduce variable scope.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1042,6 +1042,11 @@ typedef struc
> On Nov 22, 2020, at 9:22 PM, Jürgen Groß wrote:
>
> On 22.11.20 22:44, Andy Lutomirski wrote:
>>> On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote:
>>>
>>> On 20.11.20 12:59, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
> +static __alwa
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
This case can occur when combining empty lists
obj-y :=
...
obj-y += $(empty)
or
obj-y := $(empty) $(empty)
where (only) blanks would accumulate. This was only a latent issue until
now, but would become an active issue for Arm once lib/ gets populated
with all respective objects going into the
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
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
... into its own CU, to build it into an archive.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
---
xen/common/lib.c | 39 --
xen/lib/Makefile | 1 +
xen/lib/parse-size.c | 50
3 files changed, 51 insertio
... into its own CU, for being unrelated to other things in
common/lib.c.
Signed-off-by: Jan Beulich
---
xen/common/lib.c | 14 --
xen/lib/Makefile | 1 +
xen/lib/ctors.c | 25 +
3 files changed, 26 insertions(+), 14 deletions(-)
create mode 100644 xen/lib/
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() and an instance of trailing whitespace.
Signed-off-by: Jan Beulich
---
xen/comm
Convert this code to an inline function (backed by an instance in an
archive in case the compiler decides against inlining), which results
in not having it in x86 final binaries. This saves a little bit of dead
code.
Signed-off-by: Jan Beulich
---
xen/common/Makefile| 1 -
xen/common/bs
Build this code into an archive, partly paralleling bsearch().
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
---
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}/sor
On Mon, Nov 23, 2020 at 01:40:12PM +0100, Jan Beulich wrote:
> Use of __acpi_map_table() here was at least close to an abuse already
> before, but it will now consistently return NULL here. Drop the layering
> violation and use set_fixmap() directly. Re-use of the ACPI fixmap area
> is hopefully go
On 23.11.2020 16:24, Roger Pau Monné wrote:
> On Mon, Nov 23, 2020 at 01:40:12PM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/acpi/power.c
>> +++ b/xen/arch/x86/acpi/power.c
>> @@ -174,17 +174,20 @@ static void acpi_sleep_prepare(u32 state
>> if ( state != ACPI_STATE_S3 )
>> return
On Mon, Nov 23, 2020 at 01:40:30PM +0100, Jan Beulich wrote:
> Use of __acpi_map_table() is kind of an abuse here, and doesn't work
> anymore for the majority of cases if any of the tables lives outside the
> low first Mb. Keep this (ab)use only prior to reaching SYS_STATE_boot,
> primarily to avoi
On Mon, Nov 23, 2020 at 01:41:06PM +0100, Jan Beulich wrote:
> We can be more tolerant as long as the data collected from FACS is only
> needed to enter S3. A prior change already added suitable checking to
> acpi_enter_sleep().
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks,
On 23.11.20 16:56, Jan Beulich wrote:
Hi Jan, Paul
On 23.11.2020 15:39, Oleksandr wrote:
As it was agreed, below the list of proposed renaming (naming) within
current series.
Thanks for compiling this. A couple of suggestions for consideration:
1. Global (existing):
hvm_map_mem_type_to_io
On Sat, 21 Nov 2020, James Bottomley
wrote:
> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
>> A difficult part of automating commits is composing the subsystem
>> preamble in the commit log. For the ongoing effort of a fixer
>> producing
>> one or two fixes a release the use of 'tre
> -Original Message-
> From: Oleksandr
> Sent: 23 November 2020 15:48
> To: Jan Beulich ; Paul Durrant
> Cc: Oleksandr Tyshchenko ; Andrew Cooper
> ;
> Roger Pau Monné ; Wei Liu ; George Dunlap
> ; Ian Jackson ; Julien Grall
> ; Stefano
> Stabellini ; Jun Nakajima ;
> Kevin Tian
> ; Ju
flight 156956 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156956/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail pass in 156935
test-amd64-i386-xl-qemuu-debianh
On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches. Let's be conservative and assume th
There was no feedback to this series within the past three weeks.
Please review this series.
Thanks,
Olaf
Am Thu, 29 Oct 2020 18:19:40 +0100
schrieb Olaf Hering :
> The current live migration code can easily saturate an 1Gb link.
> There is still room for improvement with faster network connect
Ian Jackson has agreed to be the release manager for 4.15. Signify
this by giving him maintainership over CHANGELOG.md.
Signed-off-by: George Dunlap
---
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
CC: Roger Pau Monne
CC: Stefano Stabellini
CC: Julien Grall
CC: Paul Durra
1 - 100 of 172 matches
Mail list logo
