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 both that
> and the current 'apic' seem to be a little overly generic for a global
> variable.
The 'apic' affects only th
Hi Richard,
Em Wed, 28 Oct 2020 10:44:27 -0700
Richard Cochran escreveu:
> On Wed, Oct 28, 2020 at 03:23:18PM +0100, Mauro Carvalho Chehab wrote:
>
> > diff --git a/Documentation/ABI/testing/sysfs-uevent
> > b/Documentation/ABI/testing/sysfs-uevent
> > index aa39f8d7bcdf..d0893dad3f38 100644
>
Hi Oleksandr,
I would like to try this on my arm64 board.
According to your comments in the patch, I made this config file.
# cat debian.conf
name = "debian"
type = "pvh"
vcpus = 8
memory = 512
kernel = "/opt/agl/vmlinuz-5.9.0-1-arm64"
ramdisk = "/opt/agl/initrd.img-5.9.0-1-arm64"
cmdline= "conso
flight 156273 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156273/
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 156268 xen-unstable real [real]
flight 156289 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156268/
http://logs.test-lab.xenproject.org/osstest/logs/156289/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On 28.10.2020 19:13, Anthony PERARD wrote:
> On Tue, Oct 27, 2020 at 12:06:56PM +0100, Jan Beulich wrote:
>> On 27.10.2020 11:57, Andrew Cooper wrote:
>>> On 27/10/2020 10:37, Jan Beulich wrote:
On 27.10.2020 11:27, Olaf Hering wrote:
> Am Tue, 27 Oct 2020 11:16:04 +0100
> schrieb Jan
On 28.10.2020 22:31, Andrew Cooper wrote:
> On 26/10/2020 09:40, Jan Beulich wrote:
>> In the case that no 64-bit SYSCALL callback is registered, the guest
>> will be crashed when 64-bit userspace executes a SYSCALL instruction,
>> which would be a userspace => kernel DoS. Similarly for 32-bit
>>
On 29.10.2020 09:22, Olaf Hering wrote:
> During boot of xen.git#staging, Xen seems to think something pressed debug
> keys very early, which shows various call traces in 'xl dmesg'. A reboot may
> "fix" it, and no traces are printed.
I'm seeing the same every now and then, albeit only with a si
On 29/10/2020 08:22, Olaf Hering wrote:
> During boot of xen.git#staging, Xen seems to think something pressed debug
> keys very early, which shows various call traces in 'xl dmesg'. A reboot may
> "fix" it, and no traces are printed.
>
> Any idea what may cause this behavior? I do not see it on
Am Thu, 29 Oct 2020 09:13:08 +
schrieb Andrew Cooper :
> You'll need NR_CPUS configured to 512 to boot properly on this system.
Ah, thanks. My builds use the built-in defaults. I will adjust my future builds.
Olaf
pgpr5K1K_ZLum.pgp
Description: Digitale Signatur von OpenPGP
Am Thu, 29 Oct 2020 10:10:51 +0100
schrieb Jan Beulich :
> I've been assuming this is stuff left in the serial port's input
> latch or FIFO.
Weird, there is no `ipmitool` attached to this host.
Maybe the firmware does funny things...
Olaf
pgpQfM2XzJkIH.pgp
Description: Digitale Signatur von
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 both that
> > and the current 'apic' seem to be a little ove
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 for it could deadlock the system.
>> Add a warning during boot
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 be nice to enable CONFIG_XEN for aarch64-softmmu to
>> make it not
On Thu, Oct 29, 2020 at 09:47:09AM +0100, Jan Beulich wrote:
> On 28.10.2020 19:13, Anthony PERARD wrote:
> > On Tue, Oct 27, 2020 at 12:06:56PM +0100, Jan Beulich wrote:
> >> On 27.10.2020 11:57, Andrew Cooper wrote:
> >>> On 27/10/2020 10:37, Jan Beulich wrote:
> On 27.10.2020 11:27, Olaf He
Am Thu, 29 Oct 2020 10:57:15 +
schrieb Anthony PERARD :
> we need to add '.DELETE_ON_ERROR:'
The last paragraph at
https://www.gnu.org/software/make/manual/html_node/Errors.html#Errors suggests
that this is a good thing to have.
Olaf
pgp60XmNfzvTX.pgp
Description: Digitale Signatur von
flight 156270 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156270/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3b87d728742fe58f427f4b775b11250e29d75cc6
baseline version:
ovmf eb520b93d279e901a593c
On 29.10.2020 11:57, Anthony PERARD wrote:
> On Thu, Oct 29, 2020 at 09:47:09AM +0100, Jan Beulich wrote:
>> On 28.10.2020 19:13, Anthony PERARD wrote:
>>> On Tue, Oct 27, 2020 at 12:06:56PM +0100, Jan Beulich wrote:
On 27.10.2020 11:57, Andrew Cooper wrote:
> On 27/10/2020 10:37, Jan Beul
On 29.10.2020 09:53, Jan Beulich wrote:
> On 28.10.2020 22:31, Andrew Cooper wrote:
>> On 26/10/2020 09:40, Jan Beulich wrote:
>>> In the case that no 64-bit SYSCALL callback is registered, the guest
>>> will be crashed when 64-bit userspace executes a SYSCALL instruction,
>>> which would be a user
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
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
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-
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
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 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
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 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
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 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:
/*
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: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 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 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 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
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,
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]
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
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
> 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
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
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
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
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.
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
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
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
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
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
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) +
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
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 @@
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
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
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
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 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 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/
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
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
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 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
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
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
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
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
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 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 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 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 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
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 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
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 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
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
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, 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
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, 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
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
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, 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: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
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
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: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
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 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
1 - 100 of 119 matches
Mail list logo
