On 06.02.2021 10:09, Julien Grall wrote:
> On 01/02/2021 14:56, Jan Beulich wrote:
>> Going through an intermediate *.new file requires telling the compiler
>> what the real target is, so that the inclusion of the resulting .*.d
>> file will actually be useful.
>>
>> Fixes: 7d2d7a43d014 ("x86/build
flight 159110 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159110/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
Hi Juergen,
On 07/02/2021 12:58, Jürgen Groß wrote:
On 06.02.21 19:46, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
The first three patches are fixes for XSA-332. The avoid WARN splats
and a performance issue with interdomain events.
Thanks for helping to figure
Hi,
On 06/02/2021 11:09, Julien Grall wrote:
Hi Stefano,
On 06/02/2021 00:38, Stefano Stabellini wrote:
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
Doh :/.
The offending chunk is: >
#define gnttab_need_iommu_mapping(d) \
- (is_domain_direct_mapped(d)
On 06.02.2021 11:49, Juergen Gross wrote:
> The ring buffer for user events is used in the local system only, so
> smp barriers are fine for ensuring consistency.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Albeit I think "local system" is at least a
On Mon, Feb 01, 2021 at 01:43:28PM +0100, Jan Beulich wrote:
> While doing this for small amounts may be okay, the unconditional use
> of CPU0's value here has been found to be a problem when the boot time
> TSC of the BSP was behind that of all APs by more than a second. In
> particular because of
On 08.02.21 10:11, Julien Grall wrote:
Hi Juergen,
On 07/02/2021 12:58, Jürgen Groß wrote:
On 06.02.21 19:46, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
The first three patches are fixes for XSA-332. The avoid WARN splats
and a performance issue with interdomai
On 08.02.21 10:38, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
The ring buffer for user events is used in the local system only, so
smp barriers are fine for ensuring consistency.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Albeit I th
On 06/02/2021 10:49, Juergen Gross wrote:
> The ring buffer for user events is used in the local system only, so
> smp barriers are fine for ensuring consistency.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Juergen Gross
These need to be virt_* to not break in UP builds (on non-x86).
~Andre
On 06.02.2021 11:49, Juergen Gross wrote:
> In evtchn_read() use READ_ONCE() for reading the producer index in
> order to avoid the compiler generating multiple accesses.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/xen/evtchn.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
On 08.02.2021 10:44, Andrew Cooper wrote:
> On 06/02/2021 10:49, Juergen Gross wrote:
>> The ring buffer for user events is used in the local system only, so
>> smp barriers are fine for ensuring consistency.
>>
>> Reported-by: Andrew Cooper
>> Signed-off-by: Juergen Gross
>
> These need to be v
On 08/02/2021 09:41, Jürgen Groß wrote:
On 08.02.21 10:11, Julien Grall wrote:
Hi Juergen,
On 07/02/2021 12:58, Jürgen Groß wrote:
On 06.02.21 19:46, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
The first three patches are fixes for XSA-332. The avoid WARN sp
On 06.02.2021 11:49, Juergen Gross wrote:
> @@ -1798,6 +1818,29 @@ static void mask_ack_dynirq(struct irq_data *data)
> ack_dynirq(data);
> }
>
> +static void lateeoi_ack_dynirq(struct irq_data *data)
> +{
> + struct irq_info *info = info_for_irq(data->irq);
> + evtchn_port_t evtch
On 2021-02-06 10:49, Juergen Gross wrote:
> An event channel should be kept masked when an eoi is pending for it.
> When being migrated to another cpu it might be unmasked, though.
>
> In order to avoid this keep two different flags for each event channel
> to be able to distinguish "normal" maski
On 08.02.21 11:06, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
@@ -1798,6 +1818,29 @@ static void mask_ack_dynirq(struct irq_data *data)
ack_dynirq(data);
}
+static void lateeoi_ack_dynirq(struct irq_data *data)
+{
+ struct irq_info *info = info_for_irq(data-
On 08.02.21 10:54, Julien Grall wrote:
On 08/02/2021 09:41, Jürgen Groß wrote:
On 08.02.21 10:11, Julien Grall wrote:
Hi Juergen,
On 07/02/2021 12:58, Jürgen Groß wrote:
On 06.02.21 19:46, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
The first three patches a
On 08/02/2021 09:50, Jan Beulich wrote:
> On 08.02.2021 10:44, Andrew Cooper wrote:
>> On 06/02/2021 10:49, Juergen Gross wrote:
>>> The ring buffer for user events is used in the local system only, so
>>> smp barriers are fine for ensuring consistency.
>>>
>>> Reported-by: Andrew Cooper
>>> Signe
On 08.02.21 11:23, Andrew Cooper wrote:
On 08/02/2021 09:50, Jan Beulich wrote:
On 08.02.2021 10:44, Andrew Cooper wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
The ring buffer for user events is used in the local system only, so
smp barriers are fine for ensuring consistency.
Reported-by:
On 08/02/2021 10:25, Jürgen Groß wrote:
> On 08.02.21 11:23, Andrew Cooper wrote:
>> On 08/02/2021 09:50, Jan Beulich wrote:
>>> On 08.02.2021 10:44, Andrew Cooper wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
> The ring buffer for user events is used in the local system only, so
>
On 08.02.2021 11:23, Andrew Cooper wrote:
> On 08/02/2021 09:50, Jan Beulich wrote:
>> On 08.02.2021 10:44, Andrew Cooper wrote:
>>> On 06/02/2021 10:49, Juergen Gross wrote:
The ring buffer for user events is used in the local system only, so
smp barriers are fine for ensuring consistenc
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is to
re-use what's already existing rather than trying to re-invent the
wheel with an extra lock (or whatever we can come up).
The diffe
On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
---
drivers/xen/evtchn.c | 2 +-
1 file changed, 1 insert
On 08/02/2021 10:36, Jan Beulich wrote:
> On 08.02.2021 11:23, Andrew Cooper wrote:
>> On 08/02/2021 09:50, Jan Beulich wrote:
>>> On 08.02.2021 10:44, Andrew Cooper wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
> The ring buffer for user events is used in the local system only, so
flight 159113 linux-5.4 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159113/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-arm64
flight 159118 libvirt running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159118/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 159120 xen-4.11-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159120/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev broken
build-amd64-p
flight 159125 ovmf running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159125/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3864 host-install(4)broken REGR. vs. 159040
bu
flight 159122 qemu-mainline running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159122/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvopsbroken
build-armhf
flight 159116 linux-linus running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159116/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-arm64
flight 159111 xen-4.12-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159111/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev broken
build-amd64-x
flight 159123 xen-unstable running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159123/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev broken
build-arm64
On 08.02.2021 11:41, Jürgen Groß wrote:
> On 08.02.21 10:48, Jan Beulich wrote:
>> On 06.02.2021 11:49, Juergen Gross wrote:
>>> In evtchn_read() use READ_ONCE() for reading the producer index in
>>> order to avoid the compiler generating multiple accesses.
>>>
>>> Signed-off-by: Juergen Gross
>>>
On 05.02.2021 17:15, Roger Pau Monné wrote:
> On Mon, Feb 01, 2021 at 01:43:04PM +0100, Jan Beulich wrote:
>> The (stime,tsc) tuple is the basis for extrapolation by get_s_time().
>> Therefore the two better get taken as close to one another as possible.
>> This means two things: First, reading pla
On 08.02.21 11:51, Jan Beulich wrote:
On 08.02.2021 11:41, Jürgen Groß wrote:
On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off
On Mon, Feb 08, 2021 at 11:56:01AM +0100, Jan Beulich wrote:
> On 05.02.2021 17:15, Roger Pau Monné wrote:
> > On Mon, Feb 01, 2021 at 01:43:04PM +0100, Jan Beulich wrote:
> >> The (stime,tsc) tuple is the basis for extrapolation by get_s_time().
> >> Therefore the two better get taken as close to
On 08.02.2021 10:38, Roger Pau Monné wrote:
> On Mon, Feb 01, 2021 at 01:43:28PM +0100, Jan Beulich wrote:
>> ---
>> Since CPU0 reads its TSC last on the first iteration, if TSCs were
>> perfectly sync-ed there shouldn't ever be a need to update. However,
>> even on the TSC-reliable system I first
On 06/02/2021 10:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
---
drivers/xen/evtchn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
On 08.02.21 12:40, Julien Grall wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
---
drivers/xen/evtchn.c | 2 +-
1 file changed, 1 ins
On 08.02.2021 12:05, Roger Pau Monné wrote:
> On Mon, Feb 08, 2021 at 11:56:01AM +0100, Jan Beulich wrote:
>> On 05.02.2021 17:15, Roger Pau Monné wrote:
>>> I've been thinking this all seems doomed when Xen runs in a virtualized
>>> environment, and should likely be disabled. There's no point on t
On 08/02/2021 10:59, Jürgen Groß wrote:
On 08.02.21 11:51, Jan Beulich wrote:
Yes, but I don't see an urgent need to fix that, as there would
be thousands of accesses in the kernel needing a fix. A compiler
tearing a naturally aligned access into multiple memory accesses
would be rejected as b
On 08.02.2021 11:59, Jürgen Groß wrote:
> On 08.02.21 11:51, Jan Beulich wrote:
>> On 08.02.2021 11:41, Jürgen Groß wrote:
>>> On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
> In evtchn_read() use READ_ONCE() for reading the producer index in
> order to
Hi Juergen,
On 08/02/2021 11:48, Jürgen Groß wrote:
On 08.02.21 12:40, Julien Grall wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
---
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is to
re-use what's already existing rather than trying to re-invent the
wheel with an extra lock (
On 08.02.21 12:54, Jan Beulich wrote:
On 08.02.2021 11:59, Jürgen Groß wrote:
On 08.02.21 11:51, Jan Beulich wrote:
On 08.02.2021 11:41, Jürgen Groß wrote:
On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the produce
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is
to re-use what's already existing rather than trying
On 08.02.2021 13:15, Jürgen Groß wrote:
> On 08.02.21 12:54, Jan Beulich wrote:
>> On 08.02.2021 11:59, Jürgen Groß wrote:
>>> On 08.02.21 11:51, Jan Beulich wrote:
On 08.02.2021 11:41, Jürgen Groß wrote:
> On 08.02.21 10:48, Jan Beulich wrote:
>> On 06.02.2021 11:49, Juergen Gross wro
On 08.02.21 13:23, Jan Beulich wrote:
On 08.02.2021 13:15, Jürgen Groß wrote:
On 08.02.21 12:54, Jan Beulich wrote:
On 08.02.2021 11:59, Jürgen Groß wrote:
On 08.02.21 11:51, Jan Beulich wrote:
On 08.02.2021 11:41, Jürgen Groß wrote:
On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is
to re-use what
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how t
On Mon, Feb 08, 2021 at 12:22:25PM +0100, Jan Beulich wrote:
> On 08.02.2021 10:38, Roger Pau Monné wrote:
> > On Mon, Feb 01, 2021 at 01:43:28PM +0100, Jan Beulich wrote:
> >> ---
> >> Since CPU0 reads its TSC last on the first iteration, if TSCs were
> >> perfectly sync-ed there shouldn't ever be
flight 159136 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159136/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ovmf-amd64 3 hosts-allocate starved n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host
On 08.02.21 14:09, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien G
On 08.02.2021 14:19, Roger Pau Monné wrote:
> On Mon, Feb 08, 2021 at 12:22:25PM +0100, Jan Beulich wrote:
>> On 08.02.2021 10:38, Roger Pau Monné wrote:
>>> On Mon, Feb 01, 2021 at 01:43:28PM +0100, Jan Beulich wrote:
---
Since CPU0 reads its TSC last on the first iteration, if TSCs were
Hi Juergen,
On 08/02/2021 13:58, Jürgen Groß wrote:
On 08.02.21 14:09, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021
On 05.02.2021 21:39, Norbert Manthey wrote:
> To prevent leaking HVM params via L1TF and similar issues on a
> hyperthread pair, let's load values of domains as late as possible.
>
> Furthermore, speculative barriers are re-arranged to make sure we do not
> allow guests running on co-located VCPUs
flight 159138 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159138/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 159054
build-armhf
On 08/02/2021 14:20, Julien Grall wrote:
I believe this will be the case before our "lateeoi" handling is
becoming active (more precise: when our IRQ handler is returning to
handle_fasteoi_irq()), resulting in the possibility of the same race we
are experiencing now.
I am a bit confused what
On 08.02.21 15:20, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 13:58, Jürgen Groß wrote:
On 08.02.21 14:09, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien G
Am Mon, 11 Jan 2021 17:46:46 +0100
schrieb Olaf Hering :
> Move all save/restore related code from libxenguest.so into a separate
> library libxensaverestore.so.
Was this considered, in general, or for 4.15?
Olaf
pgpMHVs0dDqqC.pgp
Description: Digitale Signatur von OpenPGP
Olaf Hering writes ("[PATCH v2] tools: create libxensaverestore"):
> Move all save/restore related code from libxenguest.so into a separate
> library libxensaverestore.so. The only consumer is libxl-save-helper.
> There is no need to have the moved code mapped all the time in binaries
> where libxe
Am Mon, 8 Feb 2021 15:13:55 +
schrieb Ian Jackson :
> I assume this is not targeted for 4.15.
It is, was sent before the deadline I think.
Olaf
pgp_gjah6wNNL.pgp
Description: Digitale Signatur von OpenPGP
Olaf Hering writes ("Re: [PATCH v2] tools: create libxensaverestore"):
> Am Mon, 11 Jan 2021 17:46:46 +0100
> schrieb Olaf Hering :
>
> > Move all save/restore related code from libxenguest.so into a separate
> > library libxensaverestore.so.
>
> Was this considered, in general, or for 4.15?
I'
Olaf Hering writes ("[PATCH v20210111 03/39] docs: remove stale create example
from xl.1"):
> Maybe xm create had a feature to create a domU based on a configuration
> file. xl create requires the '-f' option to refer to a file.
> There is no code to look into XEN_CONFIG_DIR, so remove the example
Olaf Hering writes ("[PATCH v20210111 03/39] docs: remove stale create example
from xl.1"):
> Maybe xm create had a feature to create a domU based on a configuration
> file. xl create requires the '-f' option to refer to a file.
> There is no code to look into XEN_CONFIG_DIR, so remove the example
Olaf Hering writes ("[PATCH v20210111 04/39] docs: substitute XEN_CONFIG_DIR in
xl.conf.5"):
> xl(1) opens xl.conf in XEN_CONFIG_DIR.
> Substitute this variable also in the man page.
>
> Signed-off-by: Olaf Hering
> Reviewed-by: Anthony PERARD
Release-Acked-by: Ian Jackson
This is docs. Wor
Olaf Hering writes ("[PATCH v20210111 02/39] xl: use proper name for
bash_completion file"):
> Files in the bash-completion dirs should be named like the commands,
> without suffix. Without this change 'xl' will not be recognized as a
> command with completion support if BASH_COMPLETION_DIR is set
Olaf Hering writes ("[PATCH v20210111 05/39] tools: add with-xen-scriptdir
configure option"):
> In the near future all fresh installations will have an empty /etc.
> The content of this directory will not be controlled by the package
> manager anymore. One of the reasons for this move is to make
Olaf Hering writes ("[PATCH v20210111 06/39] Use XEN_SCRIPT_DIR to refer to
/etc/xen/scripts"):
> Replace all hardcoded paths to use XEN_SCRIPT_DIR to expand the actual
> location.
>
> Update .gitignore.
Reviewed-by: Ian Jackson
Release-Acked-by: Ian Jackson
Although I would have preferred t
Olaf Hering writes ("[PATCH v20210111 07/39] xl: optionally print timestamps
during xl migrate"):
> During 'xl -v.. migrate domU host' a large amount of debug is generated.
> It is difficult to map each line to the sending and receiving side.
> Also the time spent for migration is not reported.
>
Ian Jackson writes ("Re: [PATCH v20210111 06/39] Use XEN_SCRIPT_DIR to refer to
/etc/xen/scripts"):
> Olaf Hering writes ("[PATCH v20210111 06/39] Use XEN_SCRIPT_DIR to refer to
> /etc/xen/scripts"):
> > Replace all hardcoded paths to use XEN_SCRIPT_DIR to expand the actual
> > location.
> >
>
Olaf Hering writes ("[PATCH v20210111 08/39] xl: fix description of migrate
--debug"):
> xl migrate --debug used to track every pfn in every batch of pages.
> But these times are gone. Adjust the help text to tell what --debug
> is supposed to do today.
...
> -Display huge (!) amount of debug info
Olaf Hering writes ("[PATCH v20210111 32/39] tools: remove tabs from code
produced by libxl_save_msgs_gen.pl"):
> Signed-off-by: Olaf Hering
Personally I think this is busywork but I am happy to take the patch.
Release-Acked-by: Ian Jackson
Acked-by: Ian Jackson
Release risk is clearly negli
On Mon, Feb 08, 2021 at 02:59:55PM +0100, Jan Beulich wrote:
> On 08.02.2021 14:19, Roger Pau Monné wrote:
> > On Mon, Feb 08, 2021 at 12:22:25PM +0100, Jan Beulich wrote:
> >> On 08.02.2021 10:38, Roger Pau Monné wrote:
> >>> On Mon, Feb 01, 2021 at 01:43:28PM +0100, Jan Beulich wrote:
> ---
On 08/02/2021 16:25, Ian Jackson wrote:
> Olaf Hering writes ("[PATCH v20210111 08/39] xl: fix description of migrate
> --debug"):
>> xl migrate --debug used to track every pfn in every batch of pages.
>> But these times are gone. Adjust the help text to tell what --debug
>> is supposed to do toda
On Mon, Feb 08, 2021 at 12:50:09PM +0100, Jan Beulich wrote:
> On 08.02.2021 12:05, Roger Pau Monné wrote:
> > On Mon, Feb 08, 2021 at 11:56:01AM +0100, Jan Beulich wrote:
> >> On 05.02.2021 17:15, Roger Pau Monné wrote:
> >>> I've been thinking this all seems doomed when Xen runs in a virtualized
Am Mon, 8 Feb 2021 16:03:29 +
schrieb Ian Jackson :
> I suggest this commit message as a compromise:
>
> Some distros plan for fresh installations will have an empty /etc,
> whose content will not be controlled by the package manager
> anymore.
>
> To make this possible, add a knob t
Am Mon, 8 Feb 2021 16:22:54 +
schrieb Ian Jackson :
> I wonder if I can get a quick second option from someone on the API
> question. Using up a single letter option is something I don't want
> to just rush into.
Maybe put "-T" or "-t" into xl.c:main() instead, so that every command prints
Olaf Hering writes ("[PATCH v20210111 15/39] tools/guest: save: move
batch_pfns"):
> The batch_pfns array is already allocated in advance.
> Move it into the preallocated area.
I think these patche really need a review from someone who understands
the migration code. Ideally, Andy, who unfortuna
Olaf Hering writes ("Re: [PATCH v20210111 07/39] xl: optionally print
timestamps during xl migrate"):
> Am Mon, 8 Feb 2021 16:22:54 +
> schrieb Ian Jackson :
>
> > I wonder if I can get a quick second option from someone on the API
> > question. Using up a single letter option is something I
Olaf Hering writes ("Re: [PATCH v20210111 05/39] tools: add with-xen-scriptdir
configure option"):
> The reason is the ordering of assignments in the file:
> AC_ARG_WITH comes early in the file, XEN_CONFIG_DIR= is assigned much later.
Ah.
> It seems the assignments for CONFIG_DIR and XEN_CONFIG_
On Sat, 6 Feb 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 06/02/2021 00:38, Stefano Stabellini wrote:
> > Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
>
> Doh :/.
>
> > The offending chunk is: >
> > #define gnttab_need_iommu_mapping(d)\
> > -(is_domain_
Am Mon, 8 Feb 2021 17:48:31 +
schrieb Ian Jackson :
> > It seems the assignments for CONFIG_DIR and XEN_CONFIG_DIR can be moved up,
> > because $sysconfdir is expected to be set already. As a result the new
> > AC_ARG_WITH= can continue to use "$XEN_CONFIG_DIR/scripts" for the default
> > c
Olaf Hering writes ("Re: [PATCH v20210111 05/39] tools: add with-xen-scriptdir
configure option"):
> Am Mon, 8 Feb 2021 17:48:31 +
> schrieb Ian Jackson :
> > > It seems the assignments for CONFIG_DIR and XEN_CONFIG_DIR can be moved
> > > up, because $sysconfdir is expected to be set already.
Hello Stefano,
> On 6 Feb 2021, at 12:38 am, Stefano Stabellini wrote:
>
> Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
> The offending chunk is:
>
> #define gnttab_need_iommu_mapping(d)\
> -(is_domain_direct_mapped(d) && need_iommu(d))
> +(is_domain_di
flight 159140 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159140/
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 08/02/2021 18:06, Rahul Singh wrote:
On 6 Feb 2021, at 12:38 am, Stefano Stabellini wrote:
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
The offending chunk is:
#define gnttab_need_iommu_mapping(d)\
-(is_domain_direct_mapped(d) && need_iommu(d))
+
Hello Julien,
> On 8 Feb 2021, at 6:11 pm, Julien Grall wrote:
>
>
>
> On 08/02/2021 18:06, Rahul Singh wrote:
>>> On 6 Feb 2021, at 12:38 am, Stefano Stabellini
>>> wrote:
>>>
>>> Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
>>> The offending chunk is:
>>>
>>> #define gnttab
On 08/02/2021 18:19, Rahul Singh wrote:
Hello Julien,
Hi Rahul,
On 8 Feb 2021, at 6:11 pm, Julien Grall wrote:
On 08/02/2021 18:06, Rahul Singh wrote:
On 6 Feb 2021, at 12:38 am, Stefano Stabellini wrote:
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
The offending chu
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
The offending chunk is:
#define gnttab_need_iommu_mapping(d)\
-(is_domain_direct_mapped(d) && need_iommu(d))
+(is_domain_direct_mapped(d) && need_iommu_pt_sync(d))
On ARM we need gnttab_need_iommu_mapping to b
Am Mon, 8 Feb 2021 16:22:54 +
schrieb Ian Jackson :
> With my maintainer hat on: this is a useful development but I am not
> sure about the choice of -T, and the choice to make this a
> migrate-specific option. Most unix things that have an option to
> print timestamps use `-t`. But we have
On 2/8/21 3:21 PM, Jan Beulich wrote:
> On 05.02.2021 21:39, Norbert Manthey wrote:
>> To prevent leaking HVM params via L1TF and similar issues on a
>> hyperthread pair, let's load values of domains as late as possible.
>>
>> Furthermore, speculative barriers are re-arranged to make sure we do not
To prevent leaking HVM params via L1TF and similar issues on a
hyperthread pair, let's load values of domains after performing all
relevant checks, and blocking speculative execution.
Furthermore, speculative barriers are re-arranged to make sure we do not
allow guests running on co-located VCPUs
(+ Jan and Ian for RM/stable decision)
Hi Jan,
On 08/02/2021 18:49, Stefano Stabellini wrote:
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
The offending chunk is:
#define gnttab_need_iommu_mapping(d)\
-(is_domain_direct_mapped(d) && need_iommu(d))
+(
On Mon, 8 Feb 2021, Julien Grall wrote:
> (+ Jan and Ian for RM/stable decision)
>
> Hi Jan,
>
> On 08/02/2021 18:49, Stefano Stabellini wrote:
> > Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
> > The offending chunk is:
> >
> > #define gnttab_need_iommu_mapping(d)
On Mon, 8 Feb 2021 at 20:24, Stefano Stabellini wrote:
> > @Ian, I think this wants to go in 4.15. Without it, Xen may receive an IOMMU
> > fault for DMA transaction using granted page.
> >
> > > Backport: 4.12+
> > >
> > > ---
> > >
> > > Given the severity of the bug, I would like to request thi
flight 159146 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159146/
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 2/6/21 5:49 AM, Juergen Gross wrote:
> In order to support the possibility of per-device event channel
> settings (e.g. lateeoi spurious event thresholds) add a xenbus device
> pointer to struct irq_info() and modify the related event channel
> binding interfaces to take the pointer to the xen
On 2/6/21 5:49 AM, Juergen Gross wrote:
> Add sysfs nodes for each xenbus device showing event statistics (number
> of events and spurious events, number of associated event channels)
> and for setting a spurious event threshold in case a frontend is
> sending too many events without being rogue
PCI buses differ from default buses in a few important ways, so it is
important to detect them properly. Normally, PCI buses are expected to
have the following property:
device_type = "pci"
In reality, it is not always the case. To handle PCI bus nodes that
don't have the device_type property
flight 159133 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159133/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 broken in 159042
test-amd64-i386-xl-qemuu-w
1 - 100 of 118 matches
Mail list logo
