Hi Stefano,
On Thu, Oct 29, 2020 at 07:03:28PM -0700, Stefano Stabellini wrote:
> + xen-devel and libxl maintainers
>
> In short, there is a regression in libxl with the ARM vuart introduced
> by moving ARM guests to the PVH build.
>
>
> On Thu, 29 Oct 2020, Takahiro Akashi wrote:
> > On Wed, O
flight 156287 qemu-mainline real [real]
flight 156312 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156287/
http://logs.test-lab.xenproject.org/osstest/logs/156312/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Mon, Oct 19, 2020 at 10:31:37AM +0200, Jan Beulich wrote:
> With the split of libraries, I've observed a number of warnings from
> (old?) ld.
>
> Signed-off-by: Jan Beulich
> ---
> It's unclear to me whether this is ld version dependent - the pattern
> of where I've seen such warnings doesn't
flight 156310 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156310/
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
+ xen-devel and libxl maintainers
In short, there is a regression in libxl with the ARM vuart introduced
by moving ARM guests to the PVH build.
On Thu, 29 Oct 2020, Takahiro Akashi wrote:
> On Wed, Oct 28, 2020 at 02:44:16PM -0700, Stefano Stabellini wrote:
> > On Wed, 28 Oct 2020, Takahiro Akas
flight 156290 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156290/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 156285 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156285/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 155839
test-amd64-amd64-qemuu-nested-amd 20 debi
On Thu, 29 Oct 2020, Bertrand Marquis wrote:
> Hi Julien,
>
> > On 28 Oct 2020, at 18:39, Julien Grall wrote:
> >
> > Hi Bertrand,
> >
> > On 26/10/2020 16:21, Bertrand Marquis wrote:
> >> When a Cortex A57 processor is affected by CPU errata 832075, a guest
> >> not implementing the workaround
flight 156304 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156304/
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
flight 156280 xen-4.12-testing real [real]
flight 156308 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156280/
http://logs.test-lab.xenproject.org/osstest/logs/156308/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
From: Arvind Sankar
> Sent: 29 October 2020 21:35
>
> On Thu, Oct 29, 2020 at 09:41:13PM +0100, Thomas Gleixner wrote:
> > On Thu, Oct 29 2020 at 17:59, Paolo Bonzini wrote:
> > > On 29/10/20 17:56, Arvind Sankar wrote:
> > >>> For those two just add:
> > >>> struct apic *apic = x86_system
Hi Alex.
[sorry for the possible format issues]
> I assume this is wiring up the required bits of support to handle the
> IOREQ requests in QEMU?
No, it is not related to QEMU. We don't run QEMU in our system. Being
honest I have never tried to run it)
virtio-disk backend PoC is a completely s
Make the code more generic and not specific to TYPE_DEVICE.
Signed-off-by: Eduardo Habkost
---
Cc: Stefan Berger
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Paul Durrant
Cc: Kevin Wolf
Cc: Max Reitz
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: Richard Henderson
C
Every single qdev property setter function manually checks
dev->realized. We can just check dev->realized inside
qdev_property_set() instead.
The check is being added as a separate function
(qdev_prop_allow_set()) because it will become a callback later.
Signed-off-by: Eduardo Habkost
---
Cc: S
The function will be moved to common QOM code, as it is not
specific to TYPE_DEVICE anymore.
Signed-off-by: Eduardo Habkost
---
Cc: Stefan Berger
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Paul Durrant
Cc: Kevin Wolf
Cc: Max Reitz
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo
On Thu, Oct 29, 2020 at 09:41:13PM +0100, Thomas Gleixner wrote:
> On Thu, Oct 29 2020 at 17:59, Paolo Bonzini wrote:
> > On 29/10/20 17:56, Arvind Sankar wrote:
> >>> For those two just add:
> >>> struct apic *apic = x86_system_apic;
> >>> before all the assignments.
> >>> Less churn and much be
On Thu, 29 Oct 2020, Oleksandr Tyshchenko wrote:
> Hi Stefano
>
> [sorry for the possible format issue]
>
> On Thu, Oct 29, 2020 at 9:53 PM Stefano Stabellini
> wrote:
> On Thu, 29 Oct 2020, Oleksandr Tyshchenko wrote:
> > On Thu, Oct 29, 2020 at 9:42 AM Masami Hiramatsu
> wrote:
On Wed, Oct 28, 2020 at 05:37:02PM -0700, Stefano Stabellini wrote:
> On Tue, 27 Oct 2020, Elliott Mitchell wrote:
> > On Mon, Oct 26, 2020 at 06:44:27PM +, Julien Grall wrote:
> > > On 26/10/2020 16:03, Elliott Mitchell wrote:
> > > > On Mon, Oct 26, 2020 at 01:31:42PM +, Julien Grall wrot
Hi Stefano
[sorry for the possible format issue]
On Thu, Oct 29, 2020 at 9:53 PM Stefano Stabellini
wrote:
> On Thu, 29 Oct 2020, Oleksandr Tyshchenko wrote:
> > On Thu, Oct 29, 2020 at 9:42 AM Masami Hiramatsu <
> masami.hirama...@linaro.org> wrote:
> > Hi Oleksandr,
> >
> > Hi Masami
>
At 14:40 +0100 on 29 Oct (1603982415), Jan Beulich wrote:
> Tim,
>
> unless you tell me otherwise I'm intending to commit the latter
> two with Roger's acks some time next week. Of course it would
> still be nice to know your view on the first of the TBDs in
> patch 3 (which may result in further
At 16:42 +0100 on 28 Oct (1603903365), Jan Beulich wrote:
> Luckily sh_remove_all_mappings()'s use of the parameter is limited to
> generation of log messages. Nevertheless we'd better pass correct GFNs
> around:
> - the incoming GFN, when replacing a large page, may not be large page
> aligned,
At 10:24 +0100 on 28 Oct (1603880693), Jan Beulich wrote:
> Fair parts of the present handlers are identical; in fact
> nestedp2m_write_p2m_entry() lacks a call to p2m_entry_modify(). Move
> common parts right into write_p2m_entry(), splitting the hooks into a
> "pre" one (needed just by shadow cod
On Thu, Oct 29 2020 at 17:59, Paolo Bonzini wrote:
> On 29/10/20 17:56, Arvind Sankar wrote:
>>> For those two just add:
>>> struct apic *apic = x86_system_apic;
>>> before all the assignments.
>>> Less churn and much better code.
>>>
>> Why would it be better code?
>>
>
> I think he means the
At 10:22 +0100 on 28 Oct (1603880578), Jan Beulich wrote:
> The struct paging_mode instances get set to the same functions
> regardless of mode by both HAP and shadow code, hence there's no point
> having this hook there. The hook also doesn't need moving elsewhere - we
> can directly use struct p2
At 10:45 +0200 on 19 Oct (1603104300), Jan Beulich wrote:
> With them depending on just the number of shadow levels, there's no need
> for more than one instance of them, and hence no need for any hook (IOW
> 452219e24648 ["x86/shadow: monitor table is HVM-only"] didn't go quite
> far enough). Move
On Thu, 29 Oct 2020, Bertrand Marquis wrote:
> > On 28 Oct 2020, at 19:12, Julien Grall wrote:
> > On 26/10/2020 11:03, Rahul Singh wrote:
> >> Hello Julien,
> >>> On 23 Oct 2020, at 4:19 pm, Julien Grall wrote:
> >>> On 23/10/2020 15:27, Rahul Singh wrote:
> Hello Julien,
> > On 23 Oct
At 10:44 +0200 on 19 Oct (1603104271), Jan Beulich wrote:
> By passing the functions an MFN and flags, only a single instance of
> each is needed; they were pretty large for being inline functions
> anyway.
>
> While moving the code, also adjust coding style and add const where
> sensible / possib
On Thu, 29 Oct 2020, Alex Bennée wrote:
> Oleksandr Tyshchenko writes:
> > On Thu, Oct 29, 2020 at 9:42 AM Masami Hiramatsu <
> > masami.hirama...@linaro.org> wrote:
> >
> >> Hi Oleksandr,
> >>
> > Hi Masami
> >
> > [sorry for the possible format issue]
> >
> >
> >>
> >> I would like to try this o
On Thu, 29 Oct 2020, Alex Bennée wrote:
> > On Wed, 28 Oct 2020, Alex Bennée wrote:
> >> Xen is supported on aarch64 although weirdly using the i386-softmmu
> >> model. Checking based on the host CPU meant we never enabled Xen
> >> support. It would be nice to enable CONFIG_XEN for aarch64-softmmu
Oleksandr Tyshchenko writes:
> On Thu, Oct 29, 2020 at 9:42 AM Masami Hiramatsu <
> masami.hirama...@linaro.org> wrote:
>
>> Hi Oleksandr,
>>
> Hi Masami
>
> [sorry for the possible format issue]
>
>
>>
>> I would like to try this on my arm64 board.
>>
> Glad to hear you are interested in this
On Thu, Oct 29, 2020 at 05:38:17PM +0100, Jan Beulich wrote:
> On 29.10.2020 16:20, Roger Pau Monne wrote:
> > On slow systems with sync_console saving or loading the context of big
> > guests can cause the watchdog to trigger. Fix this by adding a couple
> > of process_pending_softirqs.
>
> Which
The current live migration code can easily saturate an 1Gb link.
There is still room for improvement with faster network connections.
Even with this series reviewed and applied.
See description of patch #6.
Olaf
Olaf Hering (23):
tools: add readv_exact to libxenctrl
tools: add xc_is_known_pag
On Thu, 29 Oct 2020, Jason Andryuk wrote:
> On Thu, Oct 29, 2020 at 6:01 AM Alex Bennée wrote:
> >
> >
> > Stefano Stabellini writes:
> >
> > > On Wed, 28 Oct 2020, Alex Bennée wrote:
> > >> Xen is supported on aarch64 although weirdly using the i386-softmmu
> > >> model. Checking based on the ho
On Thu, 29 Oct 2020, Jürgen Groß wrote:
> On 29.10.20 01:37, Stefano Stabellini wrote:
> > On Tue, 27 Oct 2020, Elliott Mitchell wrote:
> > > On Mon, Oct 26, 2020 at 06:44:27PM +, Julien Grall wrote:
> > > > On 26/10/2020 16:03, Elliott Mitchell wrote:
> > > > > On Mon, Oct 26, 2020 at 01:31:42
On Thu, 29 Oct 2020, Oleksandr Tyshchenko wrote:
> On Thu, Oct 29, 2020 at 9:42 AM Masami Hiramatsu
> wrote:
> Hi Oleksandr,
>
> Hi Masami
>
> [sorry for the possible format issue]
>
>
> I would like to try this on my arm64 board.
>
> Glad to hear you are interested in this topi
flight 156277 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156277/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install
fail like 156034
test-amd64-i386-x
On 29/10/2020 14:37, Jan Beulich wrote:
> On 29.10.2020 15:00, Andrew Cooper wrote:
>> This comment has been around since c/s 1372bca0615 in 2004. It is stale, as
>> it predates the introduction of struct vcpu.
> That commit only moved it around; it's 22a857bde9b8 afaics from
> early 2003 where it
The device model state saved by QMP xen-save-devices-state doesn't
include the vmdesc json. When restoring an HVM, xen-load-devices-state
always triggers "Expected vmdescription section, but got 0". This is
not a problem when restore comes from a file. However, when QEMU runs
in a linux stubdom
On Thu, Oct 29, 2020 at 9:42 AM Masami Hiramatsu <
masami.hirama...@linaro.org> wrote:
> Hi Oleksandr,
>
Hi Masami
[sorry for the possible format issue]
>
> I would like to try this on my arm64 board.
>
Glad to hear you are interested in this topic.
>
> According to your comments in the patch
On 29/10/2020 15:14, Jan Beulich wrote:
> Even if only part of a hypercall completed before getting preempted,
> invalidation ought to occur. Therefore fold the two return statements.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 29/10/2020 17:09, Jan Beulich wrote:
> To do its compat translation, shim code needs to include the compat
> header. For this to work, this header first of all needs to be
> generated.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 29/10/2020 17:10, Jan Beulich wrote:
> The only reference into the code controlled by this option is from the
> hypercall table, and that hypercall table entry gets overwritten.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 29/10/2020 15:01, Jan Beulich wrote:
> These are VEX-encoded equivalents of the EVEX-encoded AVX512-VNNI ISA
> extension.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On Thu, Oct 29, 2020 at 05:59:54PM +0100, Paolo Bonzini wrote:
> On 29/10/20 17:56, Arvind Sankar wrote:
> >> For those two just add:
> >>struct apic *apic = x86_system_apic;
> >> before all the assignments.
> >> Less churn and much better code.
> >>
> > Why would it be better code?
> >
>
> I
handle_page_data must be able to read directly into mapped guest memory.
This will avoid unneccesary memcpy calls for data which can be consumed
verbatim.
Rearrange the code to allow decisions based on the incoming record.
This change is preparation for future changes in handle_page_data,
no cha
Remove allocation from hotpath, move populate_pfns mfns array into preallocated
space.
Use some prefix to avoid conflict with an array used in handle_page_data.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 2 ++
tools/libs/guest/xg_sr_restore.c | 5 ++---
2 files changed, 4
Read incoming migration stream directly into the guest memory.
This avoids the memory allocation and copying, and the resulting
performance penalty.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 1 +
tools/libs/guest/xg_sr_restore.c | 132 ++-
2
Verify pfn type on sending side, also verify incoming batch of pfns.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_restore.c | 3 +--
tools/libs/guest/xg_sr_save.c| 6 ++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/libs/guest/xg_sr_restore.c b/tools/libs/
The hotpath 'send_dirty_pages' is supposed to do just one thing: sending.
The other end 'handle_page_data' is supposed to do just receiving.
But instead both do other costly work like memory allocations and data moving.
Do the allocations once, the array sizes are a compiletime constant.
Avoid unn
Remove allocation from hotpath, move types array into preallocated space.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 2 ++
tools/libs/guest/xg_sr_save.c | 7 ++-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/libs/guest/xg_sr_common.h b/tools/lib
Remove allocation from hotpath, move mfns array into preallocated space.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 2 ++
tools/libs/guest/xg_sr_restore.c | 5 ++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/tools/libs/guest/xg_sr_common.h b/tools/libs
The batch_pfns array is already allocated in advance.
Move it into the preallocated area.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 2 +-
tools/libs/guest/xg_sr_save.c | 25 +++--
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/tools
Remove allocation from hotpath, move types array into preallocated space.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 1 +
tools/libs/guest/xg_sr_restore.c | 12 +---
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/tools/libs/guest/xg_sr_common.h b/
Remove allocation from hotpath, move mfns array into preallocated space.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 2 ++
tools/libs/guest/xg_sr_save.c | 7 ++-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/libs/guest/xg_sr_common.h b/tools/libs
Remove allocation from hotpath, move guest_data array into preallocated space.
Because this was allocated with calloc:
Adjust the loop to clear unused entries as needed.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 2 ++
tools/libs/guest/xg_sr_save.c | 11 ++-
2 f
Remove allocation from hotpath, move rec_pfns array into preallocated space.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 2 ++
tools/libs/guest/xg_sr_save.c | 11 +--
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/tools/libs/guest/xg_sr_common.h b
handle_page_data must be able to read directly into mapped guest memory.
This will avoid unneccesary memcpy calls for data that can be consumed verbatim.
Split the various steps of record processing:
- move processing to handle_buffered_page_data
- adjust xenforeignmemory_map to set errno in case
Introduce a helper which decides if a given pfn type has data
for the migration stream.
No change in behavior intended.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 17
tools/libs/guest/xg_sr_restore.c | 34 +---
tools/libs/guest
Remove allocation from hotpath, move populate_pfns' pfns array into
preallocated space.
Use some prefix to avoid conflict with an array used in handle_page_data.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 1 +
tools/libs/guest/xg_sr_restore.c | 11 +--
2 files ch
Remove allocation from hotpath, move local_pages array into preallocated space.
Adjust the code to use the src page as is in case of HVM.
In case of PV the page may need to be normalised, use an private memory
area for this purpose.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h
Remove allocation from hotpath, move errors array into preallocated space.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 2 ++
tools/libs/guest/xg_sr_save.c | 7 ++-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/libs/guest/xg_sr_common.h b/tools/li
Remove allocation from hotpath, move map_errs array into preallocated space.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 1 +
tools/libs/guest/xg_sr_restore.c | 12 +---
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/tools/libs/guest/xg_sr_common.h
Remove allocation from hotpath, move iov array into preallocated space.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 2 ++
tools/libs/guest/xg_sr_save.c | 7 ++-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/libs/guest/xg_sr_common.h b/tools/libs/
Read a batch of iovec's.
In the common case of short reads, finish individual iov's with read_exact.
Signed-off-by: Olaf Hering
---
tools/libs/ctrl/xc_private.c | 54 +++-
tools/libs/ctrl/xc_private.h | 1 +
2 files changed, 54 insertions(+), 1 deletion(-)
diff
Show how fast domU pages are transferred in each iteration.
The relevant data is how fast the pfns travel, not so much how much
protocol overhead exists. So the reported MiB/sec is just for pfns.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 2 ++
tools/libs/guest/xg_sr_save
Remove allocation from hotpath, move pfns array into preallocated space.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 2 ++
tools/libs/guest/xg_sr_restore.c | 6 ++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libs/guest/xg_sr_common.h b/tools/lib
Users of xc_get_pfn_type_batch may want to sanity check the data
returned by Xen. Add a simple helper for this purpose.
Signed-off-by: Olaf Hering
---
tools/libs/ctrl/xc_private.h | 33 +
1 file changed, 33 insertions(+)
diff --git a/tools/libs/ctrl/xc_private.h
On Thu, Oct 29, 2020 at 03:05:31PM +, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 28 October 2020 21:21
> >
> > From: Arnd Bergmann
> >
> > There are hundreds of warnings in a W=2 build about a local
> > variable shadowing the global 'apic' definition:
> >
> > arch/x86/kvm/lapic.h:1
On 29.10.2020 17:58, Rahul Singh wrote:
>> On 28 Oct 2020, at 3:13 pm, Rahul Singh wrote:
>>> On 28 Oct 2020, at 11:56 am, Jan Beulich wrote:
>>> On 26.10.2020 18:17, Rahul Singh wrote:
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1419,13 +1419,15 @@
The only reference into the code controlled by this option is from the
hypercall table, and that hypercall table entry gets overwritten.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/configs/pvshim_defconfig
+++ b/xen/arch/x86/configs/pvshim_defconfig
@@ -9,6 +9,7 @@ CONFIG_EXPERT=y
CONFIG_SCHE
To do its compat translation, shim code needs to include the compat
header. For this to work, this header first of all needs to be
generated.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -24,6 +24,7 @@ headers-$(CONFIG_X86) +
While Andrew reported a randconfig build failure, I started wondering
why we'd ever build in a way different from what had failed to build.
Fix the build and then switch the shim config file accordingly.
1: fix build of PV shim when !GRANT_TABLE
2: PV shim doesn't need GRANT_TABLE
Jan
On 29/10/20 17:56, Arvind Sankar wrote:
>> For those two just add:
>> struct apic *apic = x86_system_apic;
>> before all the assignments.
>> Less churn and much better code.
>>
> Why would it be better code?
>
I think he means the compiler produces better code, because it won't
read the glob
Hello Jan,
> On 28 Oct 2020, at 3:13 pm, Rahul Singh wrote:
>
> Hello Jan,
>
>> On 28 Oct 2020, at 11:56 am, Jan Beulich wrote:
>>
>> On 26.10.2020 18:17, Rahul Singh wrote:
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -1419,13 +1419,15 @@ static int
flight 156297 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156297/
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
Arnd,
On Thu, Oct 29 2020 at 10:51, Arnd Bergmann wrote:
> On Thu, Oct 29, 2020 at 8:04 AM Paolo Bonzini wrote:
>> On 28/10/20 22:20, Arnd Bergmann wrote:
>> > Avoid this by renaming the global 'apic' variable to the more descriptive
>> > 'x86_system_apic'. It was originally called 'genapic', but
The Identity Pagetable is currently being created for all HVM VMs during setup.
This was only necessary for running HVM guests on Intel CPUs where EPT was
available but unrestricted guest mode was not.
Add option to skip the creation of the Identity Pagetable via the "noidentpt"
xl config option.
On 29.10.2020 16:20, Roger Pau Monne wrote:
> On slow systems with sync_console saving or loading the context of big
> guests can cause the watchdog to trigger. Fix this by adding a couple
> of process_pending_softirqs.
Which raises the question in how far this is then also a problem
for the calle
From: Arnd Bergmann
> Sent: 29 October 2020 09:51
...
> I think ideally there would be no global variable, withall accesses
> encapsulated in function calls, possibly using static_call() optimizations
> if any of them are performance critical.
There isn't really a massive difference between global
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.
Signed-off-by: Olaf Hering
---
docs/man/xl.1.pod.in | 4 +++-
tools/xl/xl_cmdtable.c | 2 +-
2 files changed, 4 insertions(+), 2 dele
> 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 :-) and the double $ is required to
protect from ma
On slow systems with sync_console saving or loading the context of big
guests can cause the watchdog to trigger. Fix this by adding a couple
of process_pending_softirqs.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/save.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x8
Even if only part of a hypercall completed before getting preempted,
invalidation ought to occur. Therefore fold the two return statements.
Signed-off-by: Jan Beulich
---
Split off from "x86/HVM: refine when to send mapcache invalidation
request to qemu".
--- a/xen/arch/x86/hvm/hypercall.c
+++ b
From: Arnd Bergmann
> Sent: 28 October 2020 21:21
>
> From: Arnd Bergmann
>
> There are hundreds of warnings in a W=2 build about a local
> variable shadowing the global 'apic' definition:
>
> arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global
> declaration [-Wshadow]
These are VEX-encoded equivalents of the EVEX-encoded AVX512-VNNI ISA
extension.
Signed-off-by: Jan Beulich
---
SDE: -spr
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -226,6 +226,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
{"core-caps",0x0007,
On 29.10.20 15:58, Jan Beulich wrote:
On 26.10.2020 10:13, Juergen Gross wrote:
@@ -1088,13 +1098,58 @@ static int cpupool_gran_read(const struct hypfs_entry
*entry,
return copy_to_guest(uaddr, name, strlen(name) + 1) ? -EFAULT : 0;
}
+static int cpupool_gran_write(struct hypfs_entry
On 26.10.2020 10:13, Juergen Gross wrote:
> @@ -1088,13 +1098,58 @@ static int cpupool_gran_read(const struct hypfs_entry
> *entry,
> return copy_to_guest(uaddr, name, strlen(name) + 1) ? -EFAULT : 0;
> }
>
> +static int cpupool_gran_write(struct hypfs_entry_leaf *leaf,
> +
On Wed, 28 Oct 2020 15:23:18 +0100
Mauro Carvalho Chehab wrote:
> From: Mauro Carvalho Chehab
>
> Some files over there won't parse well by Sphinx.
>
> Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
> Signed-off-by: Mauro Carvalho Chehab
Query below... I'm going to guess a rebase issu
On 29.10.2020 15:40, Jürgen Groß wrote:
> On 29.10.20 15:22, Jan Beulich wrote:
>> On 22.10.2020 16:39, Juergen Gross wrote:
>>> @@ -507,6 +509,41 @@ void __init initialize_keytable(void)
>>> }
>>> }
>>>
>>> +#define CRASHACTION_SIZE 32
>>> +static char crash_debug_panic[CRASHACTION_SIZ
On 29.10.20 15:22, Jan Beulich wrote:
On 22.10.2020 16:39, Juergen Gross wrote:
When the host crashes it would sometimes be nice to have additional
debug data available which could be produced via debug keys, but
halting the server for manual intervention might be impossible due to
the need to r
On 29.10.2020 15:00, Andrew Cooper wrote:
> This comment has been around since c/s 1372bca0615 in 2004. It is stale, as
> it predates the introduction of struct vcpu.
That commit only moved it around; it's 22a857bde9b8 afaics from
early 2003 where it first appeared, where it had a reason:
/*
Hi Julien,
> On 28 Oct 2020, at 19:12, Julien Grall wrote:
>
>
>
> On 26/10/2020 11:03, Rahul Singh wrote:
>> Hello Julien,
>
> Hi Rahul,
>
>>> On 23 Oct 2020, at 4:19 pm, Julien Grall wrote:
>>>
>>>
>>>
>>> On 23/10/2020 15:27, Rahul Singh wrote:
Hello Julien,
> On 23 Oct 2020,
On 22.10.2020 16:39, Juergen Gross wrote:
> When the host crashes it would sometimes be nice to have additional
> debug data available which could be produced via debug keys, but
> halting the server for manual intervention might be impossible due to
> the need to reboot/kexec rather sooner than la
This comment has been around since c/s 1372bca0615 in 2004. It is stale, as
it predates the introduction of struct vcpu.
It is not obvious that it was even correct at the time. Where a vcpu (domain
at the time) has been configured to run is unrelated to construct the domain's
initial pagetables,
On 11.09.2020 12:34, 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. An intermediate write
On 19.10.2020 10:31, Jan Beulich wrote:
> With the split of libraries, I've observed a number of warnings from
> (old?) ld.
>
> Signed-off-by: Jan Beulich
Marek?
> ---
> It's unclear to me whether this is ld version dependent - the pattern
> of where I've seen such warnings doesn't suggest a cl
On 19.10.2020 09:21, Jan Beulich wrote:
> This again was working right only as long as $(LIBHEADER) consisted of
> just one entry.
>
> Signed-off-by: Jan Beulich
While patch 1 has become irrelevant with Juergen's more complete
change, this one is still applicable afaict.
Jan
> ---
> An alterna
flight 156269 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156269/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Tim,
On 19.10.2020 10:42, Jan Beulich wrote:
> The change addressing the shadow related build issue noticed by
> Andrew went in already. The build breakage goes beyond this
> specific combination though - PV_SHIM_EXCLUSIVE plus HVM is
> similarly an issue. This is what the 1st patch tries to take
On Thu, Oct 29, 2020 at 6:01 AM Alex Bennée wrote:
>
>
> Stefano Stabellini writes:
>
> > On Wed, 28 Oct 2020, Alex Bennée wrote:
> >> Xen is supported on aarch64 although weirdly using the i386-softmmu
> >> model. Checking based on the host CPU meant we never enabled Xen
> >> support. It would b
1 - 100 of 119 matches
Mail list logo
