On 25.01.2021 19:25, Andrew Cooper wrote:
> On 19/10/2020 14:46, Jan Beulich wrote:
>> On 08.10.2020 20:57, Paul Durrant wrote:
>>> --- /dev/null
>>> +++ b/xen/include/public/save.h
>>> @@ -0,0 +1,66 @@
>>> +/*
>>> + * save.h
>>> + *
>>> + * Structure definitions for common PV/HVM domain state that
Hi Andrew,
On 21/01/2021 21:27, Andrew Cooper wrote:
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index a073647117..d4453d2eab 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -100,6 +100,7 @@ struct xen_sysctl_tbuf_op {
#define _XEN_SYSCT
On 25.01.2021 19:42, Boris Ostrovsky wrote:
> On 21-01-25 11:22:08, Jan Beulich wrote:
>> On 22.01.2021 20:52, Boris Ostrovsky wrote:
>>> On 1/22/21 7:51 AM, Jan Beulich wrote:
On 20.01.2021 23:49, Boris Ostrovsky wrote:
> +
> +/*
> + * Accesses to unimplemented MSRs as par
On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
> --- a/xen/include/xen/dm.h
> +++ b/xen/include/xen/dm.h
> @@ -19,6 +19,8 @@
>
> #include
>
> +#include
> +
> struct dmop_args {
> domid_t domid;
> unsigned int nr_bufs;
How come this becomes necessary at this point in the series,
On 25.01.2021 22:27, Stefano Stabellini wrote:
> A recent thread [1] has exposed a couple of issues with our current way
> of handling EXPERT.
>
> 1) It is not obvious that "Configure standard Xen features (expert
> users)" is actually the famous EXPERT we keep talking about on xen-devel
>
> 2) I
On 25.01.2021 22:27, Stefano Stabellini wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -103,7 +103,7 @@ config HVM
> If unsure, say Y.
>
> config XEN_SHSTK
> - bool "Supervisor Shadow Stacks"
> + bool "Supervisor Shadow Stacks (EXPERT)"
> depends on H
On 25.01.2021 19:18, Andrew Cooper wrote:
>> +enum {
>> +DOMAIN_CONTEXT_END,
>> +DOMAIN_CONTEXT_START,
>> +/* New types go here */
>> +DOMAIN_CONTEXT_NR_TYPES
>> +};
>
> Does this enum ever end up in an API?
>
> We might be ok as we're inside __XEN_TOOLS__, but enums normally cann
Only patches 1 and 2 are strictly intended for 4.15, paralleling
the recent Dom0 side work (and re-using many of the files
introduced there, for the stubdom build), but ones up to at least
patch 6 may still want considering (and 4 already has a release
ack).
01: libxenguest: add get_unaligned_le32
Abstract xc_dom_check_gzip()'s reading of the uncompressed size into a
helper re-usable, in particular, by other decompressor code.
Sadly in the mini-os case this conflicts with other functions of the
same name (and purpose), which can't be easily replaced individually.
Yet it was requested that n
This follows the logic used for other decompression methods utilizing an
external library, albeit here we can't ignore the 32-bit size field
appended to the compressed image - its presence causes decompression to
fail. Leverage the field instead to allocate the output buffer in one
go, i.e. without
The individual decompression CUs need to only surface their top level
functions to other code. Arrange for everything else to be static, to
make sure no undue uses of that code exist or will appear without
explicitly noticing. (In some cases this also results in code size
reduction, but since this
Add a DOMPRINTF() other methods have, indicating success. To facilitate
this, introduce an "outsize" local variable and update *size as well as
*blob only once done. The latter then also avoids leaving a pointer to
freed memory in dom->kernel_blob in case of a decompression error.
Signed-off-by: J
The ones in xg_dom_decompress_unsafe.h suffice.
Signed-off-by: Jan Beulich
Acked-by: Wei Liu
---
v2: New.
--- a/tools/libs/guest/xg_dom_bzimageloader.c
+++ b/tools/libs/guest/xg_dom_bzimageloader.c
@@ -673,13 +673,6 @@ static int xc_try_zstd_decode(
#endif
-#else /* __MINIOS__ */
-
-int xc
In all cases the kernel build makes available the uncompressed size in
the final 4 bytes of the bzImage payload. Utilize this to avoid
repeated realloc()ing of the output buffer.
As a side effect this also addresses the previous mistaken return of 0
(success) from xc_try_{bzip2,lzma,xz}_decode() i
There's no need for the extra abstraction.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/common/gunzip.c
+++ b/xen/common/gunzip.c
@@ -22,7 +22,6 @@ static unsigned __initdata inptr;
static unsigned __initdata outcnt;
#define OF(args)args
-#define STA
While tools/libs/guest/xg_private.h has its own (non-conflicting for our
purposes) __init, which hence needs to be #undef-ed, there's no other
need for this abstraction.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/common/decompress.h
+++ b/xen/common/decompress
There's no need for this abstraction.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/common/lzo.c
+++ b/xen/common/lzo.c
@@ -135,8 +135,8 @@
*/
#define MAX_255_COUNT size_t)~0) / 255) - 2)
-int INIT lzo1x_decompress_safe(const unsigned char *in, size
There's no need for this abstraction.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/common/unlzma.c
+++ b/xen/common/unlzma.c
@@ -30,7 +30,7 @@
#include "decompress.h"
-static long long INIT read_int(unsigned char *ptr, int size)
+static long long __init rea
There's no need for this abstraction.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/common/lz4/decompress.c
+++ b/xen/common/lz4/decompress.c
@@ -46,8 +46,8 @@ static const int8_t dec64table[] = {0, 0
#if defined(__XEN__) || defined(__MINIOS__)
-static int I
With xen/common/decompress.h now agreeing in both build modes about
what STATIC expands to, there's no need for this abstraction anymore.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/common/decompress.h
+++ b/xen/common/decompress.h
@@ -9,7 +9,6 @@
#define ST
With xen/common/decompress.h now agreeing in both build modes about
what STATIC expands to, there's no need for this abstraction anymore.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/common/unzstd.c
+++ b/xen/common/unzstd.c
@@ -71,7 +71,7 @@
*/
#define ZSTD_
All users have been removed in earlier changes.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/arm/efi/efi-dom0.c
+++ b/xen/arch/arm/efi/efi-dom0.c
@@ -28,7 +28,7 @@
#include
#include
#include "../../../common/decompress.h"
-#define XZ_EXTERN STATIC
+#de
While for the original library's purposes these functions of course want
to be externally exposed, we don't need this, and we also don't want
this both to prevent unintended use and to keep the name space tidy.
(When functions have no callers at all, wrap them with a suitable
#ifdef.) This has the
On 26.01.2021 10:50, Jan Beulich wrote:
> There's no need for the extra abstraction.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
This, of course, is 07/15. Sorry.
Jan
> ---
> v3: New.
>
> --- a/xen/common/gunzip.c
> +++ b/xen/common/gunzip.c
> @@ -22,7 +22,6 @@ static unsign
On 26/01/2021 07:37, Jan Beulich wrote:
> On 25.01.2021 17:31, Jan Beulich wrote:
>> On 21.01.2021 22:27, Andrew Cooper wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -1068,11 +1068,35 @@ static unsigned int resource_max_frames(const
>>> struct domain *d,
>>> case X
On 26/01/2021 08:58, Julien Grall wrote:
> Hi Andrew,
>
> On 21/01/2021 21:27, Andrew Cooper wrote:
>> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
>> index a073647117..d4453d2eab 100644
>> --- a/xen/include/public/sysctl.h
>> +++ b/xen/include/public/sysctl.h
>> @@ -100,6
On 26.01.2021 10:58, Andrew Cooper wrote:
> On 26/01/2021 07:37, Jan Beulich wrote:
>> On 25.01.2021 17:31, Jan Beulich wrote:
>>> On 21.01.2021 22:27, Andrew Cooper wrote:
+static int acquire_vmtrace_buf(
+struct domain *d, unsigned int id, unsigned long frame,
+unsigned int
On 25.01.2021 18:59, Andrew Cooper wrote:
> On 20/01/2021 08:06, Jan Beulich wrote:
>> On 19.01.2021 19:09, Andrew Cooper wrote:
>>> On 19/01/2021 16:48, Jan Beulich wrote:
On 19.01.2021 14:02, Andrew Cooper wrote:
> This code has been copied in 3 places, but it is problematic.
>
>
On 25.01.2021 18:17, Andrew Cooper wrote:
> On 25/01/2021 15:08, Jan Beulich wrote:
>> On 21.01.2021 22:27, Andrew Cooper wrote:
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -257,6 +257,10 @@ struct vcpu
>>> /* vPCI per-vCPU area, used to store data for long runni
flight 158620 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158620/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3a3501862f73095059bb05cc28147c8e899488f2
baseline version:
ovmf 96a9acfc527964dc5ab72
On Tue, Jan 26, 2021 at 2:54 AM Stefano Stabellini
wrote:
> On Sat, 23 Jan 2021, Jukka Kaartinen wrote:
> > Thanks for the response!
> >
> > On Sat, Jan 23, 2021 at 2:27 AM Stefano Stabellini <
> sstabell...@kernel.org> wrote:
> > + xen-devel, Roman,
> >
> >
> > On Fri, 22 Jan 2021, J
Hi,
> On 26 Jan 2021, at 09:22, Jan Beulich wrote:
>
> On 25.01.2021 22:27, Stefano Stabellini wrote:
>> A recent thread [1] has exposed a couple of issues with our current way
>> of handling EXPERT.
>>
>> 1) It is not obvious that "Configure standard Xen features (expert
>> users)" is actually
Hello,
This series has originated from the failure discovered by osstest in:
https://lore.kernel.org/xen-devel/e1l1vyr-00074y...@osstest.test-lab.xenproject.org/
The commit pointed by osstest is correct, but it triggers an underlying
shortcoming of the vPCI MSI handling which is fixed in patch 3
There are two duplicated calls to cleanup_domain_irq_pirq in
unmap_domain_pirq.
The first one in the for loop will be called with exactly the same
arguments as the call placed closer to the loop start.
The second one will only be executed when desc != NULL, and that's
already covered by the first
When force unbinding a MSI the used IRQ would get added to the domain
irq-pirq tree as -irq -pirq, thus preventing the same IRQ to be used
by the domain. Doing so for MSI allocated IRQs prevents the same IRQ
to be used for any other device, since MSI IRQs are allocated and
deallocated on demand unl
On 25.01.2021 18:46, Elliott Mitchell wrote:
> On Mon, Jan 25, 2021 at 10:56:25AM +0100, Jan Beulich wrote:
>> On 24.01.2021 05:47, Elliott Mitchell wrote:
>>>
>>> ---
>>> Changes in v2:
>>> - Include the obvious removal of the goto target. Always realize you're
>>> at the wrong place when you p
Hi,
> On 25 Jan 2021, at 21:27, Stefano Stabellini wrote:
>
> Add an "(EXPERT)" tag to the one-line description of Kconfig options
> that depend on EXPERT.
>
> Signed-off-by: Stefano Stabellini
> CC: andrew.coop...@citrix.com
> CC: george.dun...@citrix.com
> CC: i...@xenproject.org
> CC: jbeul
Plain MSI doesn't allow caching the MSI address and data fields while
the capability is enabled and not masked, hence we need to allow any
changes to those fields to update the binding of the interrupt. For
reference, the same doesn't apply to MSI-X that is allowed to cache
the data and address fie
On 26.01.2021 12:06, Bertrand Marquis wrote:
>> On 26 Jan 2021, at 09:22, Jan Beulich wrote:
>> On 25.01.2021 22:27, Stefano Stabellini wrote:
>>> @@ -77,7 +77,7 @@ config SBSA_VUART_CONSOLE
>>> SBSA Generic UART implements a subset of ARM PL011 UART.
>>>
>>> config ARM_SSBD
>>> - bool "Sp
flight 158623 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158623/
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
> On 26 Jan 2021, at 11:11, Jan Beulich wrote:
>
> On 26.01.2021 12:06, Bertrand Marquis wrote:
>>> On 26 Jan 2021, at 09:22, Jan Beulich wrote:
>>> On 25.01.2021 22:27, Stefano Stabellini wrote:
@@ -77,7 +77,7 @@ config SBSA_VUART_CONSOLE
SBSA Generic UART implements a subset o
flight 158617 xen-unstable real [real]
flight 158625 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158617/
http://logs.test-lab.xenproject.org/osstest/logs/158625/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On 25.01.2021 20:37, Claudemir Todo Bom wrote:
> I've managed to get the debug messages on the screen using
> vga=text-80x50,keep and disabling all messages from the kernel. Two
> images are attached with the output running the debug patch.
And the 1st of them (161303) was taken at the time of the
Jan Beulich writes ("[PATCH v3 01/15] libxenguest: add get_unaligned_le32()"):
> Abstract xc_dom_check_gzip()'s reading of the uncompressed size into a
> helper re-usable, in particular, by other decompressor code.
>
> Sadly in the mini-os case this conflicts with other functions of the
> same nam
Jan Beulich writes ("[PATCH v3 02/15] libxenguest: support zstd compressed
kernels"):
> This follows the logic used for other decompression methods utilizing an
> external library, albeit here we can't ignore the 32-bit size field
> appended to the compressed image - its presence causes decompress
Jan Beulich writes ("[PATCH v3 01/15] gunzip: drop INIT{,DATA} and STATIC"):
> There's no need for the extra abstraction.
Thanks for tidying things up.
Acked-by: Ian Jackson
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
However, I think this is a refactoring commit which wasn't
Let's make "MEMHP_MERGE_RESOURCE" consistent with "MHP_NONE", "mhp_t" and
"mhp_flags". As discussed recently [1], "mhp" is our internal
acronym for memory hotplug now.
[1]
https://lore.kernel.org/linux-mm/c37de2d0-28a1-4f7d-f944-cfd7d81c3...@redhat.com/
Cc: Andrew Morton
Cc: "K. Y. Srinivasan"
Andrew Cooper writes ("Re: [PATCH v7 08/10] tools/misc: Add xen-vmtrace tool"):
> On 22/01/2021 15:33, Ian Jackson wrote:
> > Andrew Cooper writes ("[PATCH v7 08/10] tools/misc: Add xen-vmtrace tool"):
> >> +if ( xc_vmtrace_disable(xch, domid, vcpu) )
> >> +perror("xc_vmtrace_disable()"
Jan Beulich writes ("[PATCH v3 00/15] zstd decompression for DomU-s + fallout /
consolidation"):
> Only patches 1 and 2 are strictly intended for 4.15, paralleling
> the recent Dom0 side work (and re-using many of the files
> introduced there, for the stubdom build), but ones up to at least
> patc
Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed
kernels"):
> Anyway - I guess we should continue from v3, which I hope to post
> later this morning.
Thanks, yes. I just wanted to reply to one bit of this:
> My initial attempt to avoid configure failing was to sp
On 2021/1/26 19:58, David Hildenbrand wrote:
> Let's make "MEMHP_MERGE_RESOURCE" consistent with "MHP_NONE", "mhp_t" and
> "mhp_flags". As discussed recently [1], "mhp" is our internal
> acronym for memory hotplug now.
>
> [1]
> https://lore.kernel.org/linux-mm/c37de2d0-28a1-4f7d-f944-cfd7d81c3..
flight 158619 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158619/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 26.01.2021 12:56, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH v3 01/15] gunzip: drop INIT{,DATA} and STATIC"):
>> There's no need for the extra abstraction.
>
> Thanks for tidying things up.
>
> Acked-by: Ian Jackson
Thanks.
>> Requested-by: Andrew Cooper
>> Signed-off-by: Jan Beulich
On 26/01/2021 11:59, Ian Jackson wrote:
>>> Also: at the very least, you need to trap SIGTERM SIGHUP SIGPIPE.
>>>
>>> It would be good to exit with the right signal by re-raising it.
>> This is example code, not a production utility.
> Perhaps the utility could print some kind of health warning abo
On 26.01.2021 13:05, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH v3 00/15] zstd decompression for DomU-s + fallout
> / consolidation"):
>> Only patches 1 and 2 are strictly intended for 4.15, paralleling
>> the recent Dom0 side work (and re-using many of the files
>> introduced there, for the
On 26.01.2021 12:17, Bertrand Marquis wrote:
>
>
>> On 26 Jan 2021, at 11:11, Jan Beulich wrote:
>>
>> On 26.01.2021 12:06, Bertrand Marquis wrote:
On 26 Jan 2021, at 09:22, Jan Beulich wrote:
On 25.01.2021 22:27, Stefano Stabellini wrote:
> @@ -77,7 +77,7 @@ config SBSA_VUART_CON
flight 158627 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158627/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce
UNSUPPORTED"):
> On 26.01.2021 12:17, Bertrand Marquis wrote:
> > Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
> > config parameters instead ?
> > We could also make that more clear in the help of
On 26.01.2021 14:17, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce
> UNSUPPORTED"):
>> On 26.01.2021 12:17, Bertrand Marquis wrote:
>>> Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
>>> config parameters instead ?
>>> We c
> On 26 Jan 2021, at 13:19, Jan Beulich wrote:
>
> On 26.01.2021 14:17, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce
>> UNSUPPORTED"):
>>> On 26.01.2021 12:17, Bertrand Marquis wrote:
Maybe something we could explain more clearly in the
Jan Beulich writes ("Re: [PATCH v3 00/15] zstd decompression for DomU-s +
fallout / consolidation"):
> On 26.01.2021 13:05, Ian Jackson wrote:
> > I approve of cleanups of course. But:
> >
> > Which of these cleanups were posted before the LPD ? I'm not
> > currently aware of any reason for a f
> -Original Message-
> From: Oleksandr Tyshchenko
> Sent: 25 January 2021 19:08
> To: xen-devel@lists.xenproject.org
> Cc: Julien Grall ; Jan Beulich ;
> Andrew Cooper
> ; Roger Pau Monné ; Wei Liu
> ; George
> Dunlap ; Ian Jackson ; Julien
> Grall ;
> Stefano Stabellini ; Paul Durrant
Andrew Cooper writes ("Re: [PATCH v7 08/10] tools/misc: Add xen-vmtrace tool"):
> On 26/01/2021 11:59, Ian Jackson wrote:
> >[Andrew:]
> >> This is example code, not a production utility.
> > Perhaps the utility could print some kind of health warning about it
> > possibly leaving this perf-impacti
On 21.01.2021 22:27, Andrew Cooper wrote:
> From: Michał Leszczyński
>
> Add CPUID/MSR enumeration details for Processor Trace. For now, we will only
> support its use inside VMX operation. Fill in the vmtrace_available boolean
> to activate the newly introduced common infrastructure for alloca
Hello,
The following series aims to fix some shortcomings of guest interrupt
handling when using passthrough devices. The first 5 patches are
bugfixes or cleanups, which I think should solve the issue(s) that
caused the dpci EOI timer to be introduced. However neither me nor
others seem to be able
Top word writes just update the destination of the interrupt, but
since there's no change on the masking or the triggering mode no
guest interrupt injection can result of such write. Add an assert to
that effect.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- N
When an IO-APIC pin is switched from level to edge trigger mode the
IRR bit is cleared, so it can be used as a way to EOI an interrupt at
the IO-APIC level.
Such EOI however does not get forwarded to the dpci code like it's
done for the local APIC initiated EOI. This change adds the code in
order
When the PIC is on the init sequence prevent interrupt delivery. The
state of the registers is in the process of being set during the init
phase, so it makes sense to prevent any int line changes during that
process.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
Changes since v2:
When pins are cleared from either ISR or IRR as part of the
initialization sequence forward the clearing of those pins to the dpci
EOI handler, as it is equivalent to an EOI. Not doing so can bring the
interrupt controller state out of sync with the dpci handling logic,
that expects a notification
Wait until the end of the init sequence to trigger the unmask event.
Note that it will be unconditionally triggered, but that's harmless if
not unmask actually happened.
While there change the variable type to bool.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
Changes since v2:
Current interrupt pass though code will setup a timer for each
interrupt injected to the guest that requires an EOI from the guest.
Such timer would perform two actions if the guest doesn't EOI the
interrupt before a given period of time. The first one is deasserting
the virtual line, the second is
On 26.01.2021 14:25, Ian Jackson wrote:
> I hope this explanation makes some kind of sense and sorry for the
> confusion.
It does and no, I don't think there was any confusion caused. Some
thinks merely needed clarifying, on my end at least. Thanks for
doing so.
Jan
Hi Stefano,
On 25/01/2021 21:27, Stefano Stabellini wrote:
config ARM_SSBD
- bool "Speculative Store Bypass Disable" if EXPERT
+ bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
depends on HAS_ALTERNATIVE
default y
help
@@ -87,7 +87,7 @@
On Tue, Jan 26, 2021 at 12:59 PM Jukka Kaartinen
wrote:
>
>
> On Tue, Jan 26, 2021 at 2:54 AM Stefano Stabellini
> wrote:
>
>> On Sat, 23 Jan 2021, Jukka Kaartinen wrote:
>> > Thanks for the response!
>> >
>> > On Sat, Jan 23, 2021 at 2:27 AM Stefano Stabellini <
>> sstabell...@kernel.org> wrote
On 21.01.2021 22:27, Andrew Cooper wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -155,6 +155,55 @@ void arch_get_domain_info(const struct domain *d,
> info->arch_config.emulation_flags = d->arch.emulation_flags;
> }
>
> +static int do_vmtrace_op(struct domain *d, s
On 21.01.2021 22:27, Andrew Cooper wrote:
> From: Tamas K Lengyel
>
> Implement vmtrace_reset_pt function. Properly set IPT
> state for VM forks.
>
> Signed-off-by: Tamas K Lengyel
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
albeit it strikes me as somewhat odd that ...
> --- a/
Hi Julien,
> On 26 Jan 2021, at 13:51, Julien Grall wrote:
>
> Hi Stefano,
>
> On 25/01/2021 21:27, Stefano Stabellini wrote:
>> config ARM_SSBD
>> -bool "Speculative Store Bypass Disable" if EXPERT
>> +bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
>> depend
On 21.01.2021 22:27, Andrew Cooper wrote:
> --- a/xen/arch/x86/vm_event.c
> +++ b/xen/arch/x86/vm_event.c
> @@ -251,6 +251,9 @@ void vm_event_fill_regs(vm_event_request_t *req)
>
> req->data.regs.x86.shadow_gs = ctxt.shadow_gs;
> req->data.regs.x86.dr6 = ctxt.dr6;
> +
> +if ( hvm_vm
On 26.01.2021 12:06, Roger Pau Monne wrote:
> There are two duplicated calls to cleanup_domain_irq_pirq in
> unmap_domain_pirq.
>
> The first one in the for loop will be called with exactly the same
> arguments as the call placed closer to the loop start.
I'm having trouble figuring out which two
On Tue, Jan 26, 2021 at 12:58:29PM +0100, David Hildenbrand wrote:
> Let's make "MEMHP_MERGE_RESOURCE" consistent with "MHP_NONE", "mhp_t" and
> "mhp_flags". As discussed recently [1], "mhp" is our internal
> acronym for memory hotplug now.
>
> [1]
> https://lore.kernel.org/linux-mm/c37de2d0-28a1
On Tue, Jan 26, 2021 at 12:58:29PM +0100, David Hildenbrand wrote:
> Let's make "MEMHP_MERGE_RESOURCE" consistent with "MHP_NONE", "mhp_t" and
> "mhp_flags". As discussed recently [1], "mhp" is our internal
> acronym for memory hotplug now.
>
> [1]
> https://lore.kernel.org/linux-mm/c37de2d0-28a1
Le 18/01/2021 à 11:03, Roger Pau Monné a écrit :
On Fri, Jan 15, 2021 at 03:03:26PM +, Samuel Verschelde wrote: >> Hi list, >> >>
Another "popular" thread on XCP-ng forum [1],
started in october >> 2020, allowed us to detect that patch 12 from the
XSA-332 advisory >> [2] had a very signifi
On 26.01.2021 12:06, Roger Pau Monne wrote:
> When force unbinding a MSI the used IRQ would get added to the domain
> irq-pirq tree as -irq -pirq,
I think it's -pirq at index irq, i.e. I don't think IRQ gets
negated as far as the radix tree goes. info->arch.irq gets a
negative value stored, yes.
On Tue, Jan 26, 2021 at 12:58:29PM +0100, David Hildenbrand wrote:
> Let's make "MEMHP_MERGE_RESOURCE" consistent with "MHP_NONE", "mhp_t" and
> "mhp_flags". As discussed recently [1], "mhp" is our internal
> acronym for memory hotplug now.
>
> [1]
> https://lore.kernel.org/linux-mm/c37de2d0-28a1
Le 18/01/2021 à 11:03, Roger Pau Monné a écrit :
On Fri, Jan 15, 2021 at 03:03:26PM +, Samuel Verschelde wrote:
Hi list,
Another "popular" thread on XCP-ng forum [1], started in october 2020,
allowed us to detect that patch 12 from the XSA-332 advisory [2] had a very
significant impact on n
On Tue, Jan 19, 2021 at 05:23:25PM +, Andrew Cooper wrote:
> On 19/01/2021 15:48, Roger Pau Monné wrote:
> > On Fri, Jan 15, 2021 at 11:10:46PM +, Andrew Cooper wrote:
> >> From: Norbert Kamiński
> >>
> >> For now, this is simply enough logic to let Xen come up after the
> >> bootloader
>
On 26.01.2021 12:06, Roger Pau Monne wrote:
> Plain MSI doesn't allow caching the MSI address and data fields while
> the capability is enabled and not masked, hence we need to allow any
> changes to those fields to update the binding of the interrupt. For
> reference, the same doesn't apply to MSI
On Tue, Jan 26, 2021 at 01:20:14PM +, Bertrand Marquis wrote:
>
>
> > On 26 Jan 2021, at 13:19, Jan Beulich wrote:
> >
> > On 26.01.2021 14:17, Ian Jackson wrote:
> >> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce
> >> UNSUPPORTED"):
> >>> On 26.01.2021 12:17,
On 26.01.2021 14:17, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce
> UNSUPPORTED"):
>> On 26.01.2021 12:17, Bertrand Marquis wrote:
>>> Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
>>> config parameters instead ?
>>> We c
On 26.01.2021 14:45, Roger Pau Monne wrote:
> Top word writes just update the destination of the interrupt, but
> since there's no change on the masking or the triggering mode no
> guest interrupt injection can result of such write. Add an assert to
> that effect.
>
> Requested-by: Jan Beulich
>
On 26.01.2021 14:45, Roger Pau Monne wrote:
> When an IO-APIC pin is switched from level to edge trigger mode the
> IRR bit is cleared, so it can be used as a way to EOI an interrupt at
> the IO-APIC level.
>
> Such EOI however does not get forwarded to the dpci code like it's
> done for the local
On Fri, Jan 22, 2021 at 04:14:30PM +0100, Jan Beulich wrote:
> While the lack of proper dependency tracking of #include-d files is
> wider than just the libs/ subtree, dealing with the problem universally
> there or in tools/Rules.mk is too much of a risk at this point in the
> release cycle. Add
On Tue, Jan 26, 2021 at 04:17:59PM +0100, Jan Beulich wrote:
> On 26.01.2021 12:06, Roger Pau Monne wrote:
> > Plain MSI doesn't allow caching the MSI address and data fields while
> > the capability is enabled and not masked, hence we need to allow any
> > changes to those fields to update the bin
On 26/01/2021 13:32, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH v7 08/10] tools/misc: Add xen-vmtrace
> tool"):
>> On 26/01/2021 11:59, Ian Jackson wrote:
>>> [Andrew:]
This is example code, not a production utility.
>>> Perhaps the utility could print some kind of health warning
On 21-01-26 10:05:47, Jan Beulich wrote:
> On 25.01.2021 19:42, Boris Ostrovsky wrote:
> > On 21-01-25 11:22:08, Jan Beulich wrote:
> >> On 22.01.2021 20:52, Boris Ostrovsky wrote:
> >>> On 1/22/21 7:51 AM, Jan Beulich wrote:
> On 20.01.2021 23:49, Boris Ostrovsky wrote:
> > +
> > +
On Tue, Jan 26, 2021 at 03:38:27PM +0100, Jan Beulich wrote:
> On 26.01.2021 12:06, Roger Pau Monne wrote:
> > There are two duplicated calls to cleanup_domain_irq_pirq in
> > unmap_domain_pirq.
> >
> > The first one in the for loop will be called with exactly the same
> > arguments as the call pl
flight 158639 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158639/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 26.01.2021 17:08, Roger Pau Monné wrote:
> On Tue, Jan 26, 2021 at 03:38:27PM +0100, Jan Beulich wrote:
>> On 26.01.2021 12:06, Roger Pau Monne wrote:
>>> There are two duplicated calls to cleanup_domain_irq_pirq in
>>> unmap_domain_pirq.
>>>
>>> The first one in the for loop will be called with
On Tue, Jan 26, 2021 at 03:52:54PM +0100, Jan Beulich wrote:
> On 26.01.2021 12:06, Roger Pau Monne wrote:
> > When force unbinding a MSI the used IRQ would get added to the domain
> > irq-pirq tree as -irq -pirq,
>
> I think it's -pirq at index irq, i.e. I don't think IRQ gets
> negated as far as
When discussing the shrunk down version of the commit in question it
was said (in reply to my conditional choosing of the width):
"However, the 32bit case isn't actually interesting here. A
guest can't execute a SYSCALL instruction on/across the 4G->0 boundary
because the M2P is mapped NX up to
1 - 100 of 154 matches
Mail list logo
