I have found an alarming tendency regarding changes in the OSStest
repository: over the last 2 years (or 3 Xen versions) there has been
a pattern of OSStest commits being more frequent during the RC phase
of a Xen release. On average there were about 4 commits to osstest.git
per week. The numbers
flight 132521 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132521/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 132421
test-amd64-i386-xl-qemut-win7-amd64 17
Andrii,
YEY!
I have finally got an error message!
The rest of the mail is inline.
2019年1月28日(月) 17:25 Andrii Anisov :
> Hello Jairo,
>
> On 28.01.19 19:20, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote:
>
> > I was able to compile the Xen image with earlyprintk without issue.
>
> Cool.
>
> > It
On 23.01.2019 14:03, Kees Cook wrote:
> This adds a new plugin "stackinit" that attempts to perform unconditional
> initialization of all stack variables
Hello Kees! Hello everyone!
I was curious about the performance impact of the initialization of all stack
variables. So I did a very brief
On Mon, Jan 28, 2019 at 06:39:43PM +0100, Roger Pau Monné wrote:
>On Mon, Jan 28, 2019 at 03:06:45PM +0800, Chao Gao wrote:
>> to replace the current per-cpu cache 'uci->mc'.
>>
>> Compared to the current per-cpu cache, the benefits of the global
>> microcode cache are:
>> 1. It reduces the work
flight 132550 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132550/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
flight 132514 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132514/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR.
On Mon, Jan 28, 2019 at 5:16 AM Wei Liu wrote:
>
> On Sat, Jan 26, 2019 at 10:45:07PM -0700, Tamas K Lengyel wrote:
> > On systems with XSM enabled libxl_name_to_domid leaks memory
> > allocated for ssid_label:
> >
> > ==2693== 53 bytes in 2 blocks are definitely lost in loss record 4 of 8
> >
On Mon, 28 Jan 2019, Julien Grall wrote:
> On 1/27/19 9:55 AM, Julien Grall wrote:
> > Hi,
> >
> > On 1/25/19 9:36 PM, Stefano Stabellini wrote:
> > > On Thu, 24 Jan 2019, Julien Grall wrote:
> > > > @James, please correct me if I am wrong below :).
> > > >
> > > > On 24/01/2019 00:52, Stefano
On Mon, 28 Jan 2019, Julien Grall wrote:
> The EL1 translation regime is out-of-context when running at EL2. This
> means the processor cannot speculate memory accesses using the registers
> associated to that regime.
>
> An isb() is only needed if Xen is going to use the translation regime
>
On Mon, 28 Jan 2019, Julien Grall wrote:
> Hi,
>
> On 1/26/19 1:30 AM, Stefano Stabellini wrote:
> > On Mon, 21 Jan 2019, Julien Grall wrote:
> > > Hi,
> > >
> > > Ping?
> > >
> > > Cheers,
> > >
> > > On 30/11/2018 17:25, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > Below a list of
On Mon, 28 Jan 2019, Boris Ostrovsky wrote:
> On 1/28/19 3:29 AM, Oleksandr Andrushchenko wrote:
> > +Boris and Juergen who can also help getting it in
>
> I can put this in but I'd like to have Stefano's ack, this being ARM.
The patch is OK. Sorry for not replying earlier, this thread fell off
Until xenconsoled learns how to handle multiple consoles, this is needed
for save/restore support (qemu state is transferred over secondary
consoles).
Additionally, Linux-based stubdomain waits for all the backends to
initialize during boot. Lack of some console backends results in
stubdomain
Do not prohibit anymore using stubdomain with qemu-xen.
To help distingushing MiniOS and Linux stubdomain, add helper inline
functions libxl__stubdomain_is_linux() and
libxl__stubdomain_is_linux_running(). Those should be used where really
the difference is about MiniOS/Linux, not
Add documentation based on reverse-engineered toolstack-ioemu stubdomain
protocol.
Signed-off-by: Marek Marczykowski-Górecki
---
docs/misc/stubdom.txt | 53 -
1 file changed, 53 insertions(+)
diff --git a/docs/misc/stubdom.txt b/docs/misc/stubdom.txt
This allows using arguments with spaces, like -append, without
nominating any special "separator" character.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- previous version of this patch "libxl: use \x1b to separate qemu
arguments for linux stubdomain" used specific
Access to QMP of QEMU in Linux stubdomain is possible over vchan
connection. Add appropriate handling in libxl__ev_qmp_* API, keeping all the
asynchronous properties.
Since only one client can be connected to vchan server at the same time
and it is not enforced by the libxenvchan itself,
It is not safe for multiple clients to (even try to) connect to the same
vchan server at the same time. Contrary to QMP over local socket,
connection over vchan needs external locking. For now use flock() for
this. This is not ideal for async QMP API, as flock() will block the
whole thread while
The forced vkb device is meant for better performance of qemu access
(at least according to ebbd2561b4cefb299f0f68a88b2788504223de18 "libxl:
Add a vkbd frontend/backend pair for HVM guests"), which isn't used if
there is no configured channel to actually access that keyboard.
One can still add
Signed-off-by: Marek Marczykowski-Górecki
---
tools/libxl/libxl_qmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 42c8ab8..a235095 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1452,7 +1452,7
When qemu is running in stubdomain, any attempt to initialize vnc/sdl
there will crash it (on failed attempt to load a keymap from a file). If
vfb is present, all those cases are skipped. But since
b053f0c4c9e533f3d97837cf897eb920b8355ed3 "libxl: do not start dom0 qemu
for stubdomain when not
Add documentation for upcoming Linux stubdomain for qemu-upstream.
Signed-off-by: Marek Marczykowski-Górecki
---
docs/misc/stubdom.txt | 50 -
1 file changed, 50 insertions(+)
diff --git a/docs/misc/stubdom.txt b/docs/misc/stubdom.txt
index
General idea is to allow freely set device_model_version and
device_model_stubdomain_override and choose the right options based on this
choice.
Also, allow to specific path to stubdomain kernel/ramdisk, for greater
flexibility.
First two patches add documentation about expected
libxenvchan.h include xenevtchn.h and xengnttab.h, so applications built
with it needs applicable -I in CFLAGS too.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/Rules.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/Rules.mk b/tools/Rules.mk
index
Rely on a wrapper script in stubdomain to attach FD 3/4 of qemu to
relevant consoles.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- adjust for qmp_ev*
- assume specific fdset id in qemu set in stubdomain
---
tools/libxl/libxl_dm.c | 23 +++
Let the server know when the client is connected. Otherwise server will
notice only when client send some data.
This change does not break existing clients, as libvchan user should
handle spurious notifications anyway (for example acknowledge of remote
side reading the data).
Signed-off-by: Marek
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jason Andryuk
---
docs/man/xl.cfg.5.pod.in | 23 +++
tools/xl/xl_parse.c | 7 +++
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index
From: Eric Shelton
This patch creates an appropriate command line for the QEMU instance
running in a Linux-based stubdomain.
NOTE: a number of items are not currently implemented for Linux-based
stubdomains, such as:
- save/restore
- QMP socket
- graphics output (e.g., VNC)
Signed-off-by: Eric
Access to QMP of QEMU in Linux stubdomain is possible over vchan
connection. Add appropriate handling to synchronous API.
Since only one client can be connected to vchan server at the same time
and it is not enforced by the libxenvchan itself, additional client-side
locking is needed. Note that
flight 132504 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132504/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16
guest-localmigrate/x10 fail REGR. vs.
On 1/28/19 3:29 AM, Oleksandr Andrushchenko wrote:
> +Boris and Juergen who can also help getting it in
I can put this in but I'd like to have Stefano's ack, this being ARM.
-boris
>
> On 1/28/19 8:34 AM, Souptick Joarder wrote:
>> On Mon, Jan 14, 2019 at 4:08 PM Oleksandr Andrushchenko
>>
On Mon, Jan 28, 2019 at 02:41:15PM +, Wei Liu wrote:
> On Sat, Jan 26, 2019 at 03:31:14AM +0100, Marek Marczykowski-Górecki wrote:
> > Stubdomain do not have it's own config file - its configuration is
> > derived from target domains. Do not try to manipulate it when attaching
> > PCI device.
flight 132527 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132527/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
On Mon, Jan 28, 2019 at 02:50:00PM +, Wei Liu wrote:
> On Sat, Jan 26, 2019 at 03:31:15AM +0100, Marek Marczykowski-Górecki wrote:
> > From: Simon Gaiser
> >
> > Stubdomains need to be given sufficient privilege over the guest which it
> > provides emulation for in order for PCI passthrough
flight 132511 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132511/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 132469
test-armhf-armhf-libvirt-raw 13
flight 132538 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132538/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On Sun, Jan 27, 2019 at 02:15:52PM -0800, Pry Mar wrote:
> qemu build config:
> http://paste.debian.net/plain/1062777/
>
> domU startup trace:
> http://paste.debian.net/plain/1062768/
>
> This release uses qemu-3.0.0 which has a depends on libxentoolcore.
>
> In xen-4.11.1 with qemu-2.11.2 vfb
On Mon, Jan 28, 2019 at 03:06:45PM +0800, Chao Gao wrote:
> to replace the current per-cpu cache 'uci->mc'.
>
> Compared to the current per-cpu cache, the benefits of the global
> microcode cache are:
> 1. It reduces the work that need to be done on each CPU. Parsing ucode
> file can be done once
>>> On 28.01.19 at 17:55, wrote:
> On Mon, Jan 28, 2019 at 03:06:44PM +0800, Chao Gao wrote:
>> to a more generic function. Then, this function can compare two given
>> microcodes' signature/revision as well. Comparing two microcodes is
>> used to update the global microcode cache (introduced by
On 28.01.19 18:54, Julien Grall wrote:
On 1/28/19 4:40 PM, Andrii Anisov wrote:
On 28.01.19 18:36, Julien Grall wrote:
Hold on, CA57 and CA53 are ARMv8 cores. So are you using 32-bit or 64-bit
guests?
64-bit guests.
64-bit guest should not have any Set/Way operations unless you are
On Mon, Jan 28, 2019 at 03:06:44PM +0800, Chao Gao wrote:
> to a more generic function. Then, this function can compare two given
> microcodes' signature/revision as well. Comparing two microcodes is
> used to update the global microcode cache (introduced by the later
> patches in this series)
On 1/28/19 4:40 PM, Andrii Anisov wrote:
On 28.01.19 18:36, Julien Grall wrote:
Hold on, CA57 and CA53 are ARMv8 cores. So are you using 32-bit or
64-bit guests?
64-bit guests.
64-bit guest should not have any Set/Way operations unless you are
using a very very old Linux. So what is the
On Mon, Jan 28, 2019 at 04:40:59PM +, Andrew Cooper wrote:
> Before the cpuid_policy logic came along, %cr4/EFER auditing on migrate-in was
> complicated, because at that point no CPUID information had been set for the
> guest. Auditing against the host CPUID was better than nothing, but not
>>> On 28.01.19 at 17:40, wrote:
> Before the cpuid_policy logic came along, %cr4/EFER auditing on migrate-in was
> complicated, because at that point no CPUID information had been set for the
> guest. Auditing against the host CPUID was better than nothing, but not
> ideal.
>
> Similarly at
Before the cpuid_policy logic came along, %cr4/EFER auditing on migrate-in was
complicated, because at that point no CPUID information had been set for the
guest. Auditing against the host CPUID was better than nothing, but not
ideal.
Similarly at the time, PVHv1 lacked the "CPUID passed through
On Mon, Jan 28, 2019 at 03:06:43PM +0800, Chao Gao wrote:
> This check has been done in microcode_sanity_check(). Needn't do it
> again in get_matching_microcode().
>
> Signed-off-by: Chao Gao
Reviewed-by: Roger Pau Monné
Thanks, Roger.
___
On 28.01.19 18:36, Julien Grall wrote:
Hold on, CA57 and CA53 are ARMv8 cores. So are you using 32-bit or 64-bit
guests?
64-bit guests.
64-bit guest should not have any Set/Way operations unless you are using a very
very old Linux. So what is the version of each guest?
All of them
On 1/28/19 4:32 PM, Andrii Anisov wrote:
Hello Julien,
Actually I was going to send this patch as RFC, but dropped it at the
last moment.
On 28.01.19 17:55, Julien Grall wrote:
This was missed on purpose. Let me explain why. The call to
p2m_invalidate_root() arch_domain_creation_finished
Hello Julien,
Actually I was going to send this patch as RFC, but dropped it at the last
moment.
On 28.01.19 17:55, Julien Grall wrote:
This was missed on purpose. Let me explain why. The call to
p2m_invalidate_root() arch_domain_creation_finished is called by *all* the
domain at boot to
>>> On 28.01.19 at 16:52, wrote:
> On Mon, Jan 28, 2019 at 08:30:02AM -0700, Jan Beulich wrote:
>> >>> On 28.01.19 at 15:22, wrote:
>> > In order to solve it move the vioapic_hwdom_map_gsi outside of the
>> > locked region in vioapic_write_redirent. vioapic_hwdom_map_gsi will
>> > not access any
no_irq_type handlers are used when an IRQ does not have action attached.
This is useful to detect misconfiguration between the interrupt
controller and the software.
Currently, all the handlers will do nothing on spurious interrupt. This
means if such interrupt is received, the priority of the
While SPIs are shared between CPU, it is not possible to receive the
same interrupts on a different CPU while the interrupt is in active
state. The deactivation of the interrupt is done at the end of the
handling.
This means the _IRQ_PENDING logic is unecessary on Arm as a same
interrupt can
flight 132499 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132499/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 132451
Tests which did
Hi,
On 1/28/19 3:34 PM, Andrii Anisov wrote:
From: Andrii Anisov
In case if the p2m table is shared to IOMMU, invalidating it turns IOMMU to
translation faults that could be not repaired.
Fixed patch check for the corresponded condition and has a comment for one
introduced
On 28/01/2019 15:50, Jan Beulich wrote:
On 28.01.19 at 16:36, wrote:
>> On 28/01/2019 15:22, Jan Beulich wrote:
>> On 28.01.19 at 14:56, wrote:
Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
complicated, because at that point no CPUID information had
On Mon, Jan 28, 2019 at 08:30:02AM -0700, Jan Beulich wrote:
> >>> On 28.01.19 at 15:22, wrote:
> > In order to solve it move the vioapic_hwdom_map_gsi outside of the
> > locked region in vioapic_write_redirent. vioapic_hwdom_map_gsi will
> > not access any of the vioapic fields, so there's no
On 1/28/19 8:25 AM, Andrew Cooper wrote:
> On 28/01/2019 14:19, Jan Beulich wrote:
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -218,6 +218,12 @@ static int apply_microcode(unsigned int
spin_unlock_irqrestore(_update_lock, flags);
>>> On 28.01.19 at 16:36, wrote:
> On 28/01/2019 15:22, Jan Beulich wrote:
> On 28.01.19 at 14:56, wrote:
>>> Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
>>> complicated, because at that point no CPUID information had been set for the
>>> guest. Auditing
On 28/01/2019 15:22, Jan Beulich wrote:
On 28.01.19 at 14:56, wrote:
>> Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
>> complicated, because at that point no CPUID information had been set for the
>> guest. Auditing against the host CPUID was better than
From: Andrii Anisov
In case if the p2m table is shared to IOMMU, invalidating it turns IOMMU to
translation faults that could be not repaired.
Fixed patch check for the corresponded condition and has a comment for one
introduced p2m_invalidate_root() call, but miss them for another. So put the
On 28/01/2019 15:22, Wei Liu wrote:
> On Mon, Jan 28, 2019 at 01:56:29PM +, Andrew Cooper wrote:
>> Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
>> complicated, because at that point no CPUID information had been set for the
>> guest. Auditing against the host
>>> On 28.01.19 at 15:22, wrote:
> In order to solve it move the vioapic_hwdom_map_gsi outside of the
> locked region in vioapic_write_redirent. vioapic_hwdom_map_gsi will
> not access any of the vioapic fields, so there's no need to call the
> function holding the hvm.irq_lock.
True, but you
On Mon, Jan 28, 2019 at 01:56:29PM +, Andrew Cooper wrote:
> Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
> complicated, because at that point no CPUID information had been set for the
> guest. Auditing against the host CPUID was better than nothing, but not
>
On Mon, Jan 28, 2019 at 03:22:45PM +0100, Roger Pau Monne wrote:
> The current GSI mapping code can cause the following deadlock:
>
> (XEN) *** Dumping CPU0 host state: ***
> (XEN) [ Xen-4.12.0-rc x86_64 debug=y Tainted: C ]
> [...]
> (XEN) Xen call trace:
> (XEN)[]
>>> On 28.01.19 at 15:45, wrote:
> On 1/23/19 14:37, Jan Beulich wrote:
> On 23.01.19 at 12:51, wrote:
>>> @@ -2223,7 +2231,8 @@ gnttab_transfer(
>>> okay = gnttab_prepare_for_transfer(e, d, gop.ref);
>>> spin_lock(>page_alloc_lock);
>>>
>>> -if ( unlikely(!okay)
On Sat, Jan 26, 2019 at 03:31:16AM +0100, Marek Marczykowski-Górecki wrote:
> Allow device model running in stubdomain to enable/disable MSI(-X),
> bypassing pciback. While pciback is still used to access config space
> from within stubdomain, it refuse to write to
>
On Sat, Jan 26, 2019 at 03:31:15AM +0100, Marek Marczykowski-Górecki wrote:
> From: Simon Gaiser
>
> Stubdomains need to be given sufficient privilege over the guest which it
> provides emulation for in order for PCI passthrough to work correctly.
> When a HVM domain try to enable MSI, QEMU in
On 1/23/19 14:37, Jan Beulich wrote:
On 23.01.19 at 12:51, wrote:
>> @@ -1268,7 +1272,8 @@ unmap_common(
>> }
>>
>> smp_rmb();
>> -map = _entry(lgt, op->handle);
>> +map = _entry(lgt, array_index_nospec(op->handle,
>> +
On Sat, Jan 26, 2019 at 03:31:17AM +0100, Marek Marczykowski-Górecki wrote:
> Add libxc wrapper for PHYSDEVOP_msi_msix_set_enable introduced in
> previous commit.
>
> Signed-off-by: Marek Marczykowski-Górecki
Assuming the addition of physdev ops is accepted:
Acked-by: Wei Liu
On Sat, Jan 26, 2019 at 03:31:14AM +0100, Marek Marczykowski-Górecki wrote:
> Stubdomain do not have it's own config file - its configuration is
> derived from target domains. Do not try to manipulate it when attaching
> PCI device.
>
So if we add the same configuration to stubdom as well, what
On 28/01/2019 14:19, Jan Beulich wrote:
>>> --- a/xen/arch/x86/microcode_amd.c
>>> +++ b/xen/arch/x86/microcode_amd.c
>>> @@ -218,6 +218,12 @@ static int apply_microcode(unsigned int
>>>
>>> spin_unlock_irqrestore(_update_lock, flags);
>>>
>>> +/*
>>> + * Experimentally this helps
On Sat, Jan 26, 2019 at 03:31:12AM +0100, Marek Marczykowski-Górecki wrote:
> HVM domains use IOMMU and device model assistance for communicating with
> PCI devices, xen-pcifront/pciback isn't directly needed by HVM domain.
> But pciback serve also second function - it reset the device when it is
On Sat, Jan 26, 2019 at 03:31:13AM +0100, Marek Marczykowski-Górecki wrote:
> When qemu is running in stubdomain, handling "pci-ins" command will fail
> if pcifront is not initialized already. Fix this by sending such command
> only after confirming that pciback/front is running.
>
>
>>> On 28.01.19 at 12:40, wrote:
> On 28/01/2019 09:51, Jan Beulich wrote:
>> The increased number of messages (spec_ctrl.c:print_details()) within a
>> certain time window made me notice some slowness of boot time screen
>> output. Experimentally I've narrowed the time window to be from
>>
On 1/24/19 22:05, Andrew Cooper wrote:
> On 23/01/2019 11:51, Norbert Manthey wrote:
>> Dear all,
>>
>> This patch series attempts to mitigate the issue that have been raised in the
>> XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
>> execution on Intel hardware, an
Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
complicated, because at that point no CPUID information had been set for the
guest. Auditing against the host CPUID was better than nothing, but not
ideal.
Order of information in the migration stream is still an issue
On Fri, Jan 25, 2019 at 12:34:18AM -0700, Jan Beulich wrote:
> Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
> userspace test harnesses") didn't account for the dependencies of
> cpuid-autogen.h to potentially change between incremental builds.
> In particular the harness has a
On Fri, Jan 25, 2019 at 12:33:49AM -0700, Jan Beulich wrote:
> Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
> userspace test harnesses") didn't account for the dependencies of
> cpuid-autogen.h to potentially change between incremental builds.
> Putting the make invocation to
On Thu, Jan 17, 2019 at 05:40:59PM +0100, Juergen Gross wrote:
> In case of soft reset the gnttab limit setting will fail, so omit it.
> Setting of max vcpu count is pointless in this case, too, so we can
> drop that as well.
>
> Without this patch soft reset will fail with:
>
> libxl: error:
This is a note to let you know that I've just added the patch titled
x86/entry/64/compat: Fix stack switching for XEN PV
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
x86/entry/64/compat: Fix stack switching for XEN PV
to the 4.20-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
On 1/28/19 12:12, Jan Beulich wrote:
On 28.01.19 at 12:03, wrote:
>> On 1/25/19 17:34, Jan Beulich wrote:
>> On 23.01.19 at 12:57, wrote:
@@ -212,7 +217,12 @@ static void vioapic_write_redirent(
struct hvm_irq *hvm_irq = hvm_domain_irq(d);
union
On Sat, Jan 26, 2019 at 10:45:07PM -0700, Tamas K Lengyel wrote:
> On systems with XSM enabled libxl_name_to_domid leaks memory
> allocated for ssid_label:
>
> ==2693== 53 bytes in 2 blocks are definitely lost in loss record 4 of 8
> ==2693==at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
>
On 24/01/2019 13:43, Peng Fan wrote:
> On i.MX8, we implemented partition reboot which means Cortex-A reboot
> will not impact M4 cores and System control Unit core. However GICv3
> is not reset because we also need to support A72 Cluster reboot without
> affecting A53 Cluster.
>
> The gic-v3
On 24/01/2019 13:29, Anthony PERARD wrote:
> Since libxl later during guest creation run the command "cont", it kind
> of expect that QEMU would not do any emulation, use the "-S" command
> option to make this effective. Unfortunately, when QEMU is started with
> "-S", it won't write QEMU's
On 28/01/2019 10:51, Jan Beulich wrote:
> The increased number of messages (spec_ctrl.c:print_details()) within a
> certain time window made me notice some slowness of boot time screen
> output. Experimentally I've narrowed the time window to be from
> immediately after the early ucode update on
On 28/01/2019 12:50, Julien Grall wrote:
> Hi all,
>
> Early version of Cortex-A76 can end-up with corrupt TLBs if they
> speculate an AT instruction while the S1/S2 system registers are in an
> inconsistent state.
>
> This can happen during guest context switch and when invalidating the
> TLBs
On 25/01/2019 18:06, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Currently, that assert condition does not correspond to a comment above
> and makes assertion failed on HW IRQ disconnection.
> Fix the condition so it corresponds to the comment and allows IRQ
> disconnection on debug builds.
>
On Fri, Jan 25, 2019 at 09:13:49AM -0700, Jan Beulich wrote:
On 25.01.19 at 09:26, wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -732,7 +732,11 @@ long arch_do_domctl(
>> break;
>>
>> ret = -EPERM;
>> -if ( irq <= 0 ||
Until recently, kernel/initrd/dtb were loaded using guest VA and
therefore requiring to restore temporarily the P2M. This was reworked
in a series of commits (up to 9292086 "xen/arm: domain_build: Use
copy_to_guest_phys_flush_dcache in dtb_load") to use a guest PA.
This will also help a follow-up
Early version of Cortex-A76 can end-up with corrupt TLBs if they
speculate an AT instruction while the S1/S2 system registers are in an
inconsistent state.
This can happen during guest context switch and when invalidating the
TLBs for other than the current VMID.
The workaround implemented in
Hi all,
Early version of Cortex-A76 can end-up with corrupt TLBs if they
speculate an AT instruction while the S1/S2 system registers are in an
inconsistent state.
This can happen during guest context switch and when invalidating the
TLBs for other than the current VMID.
The workaround
The EL1 translation regime is out-of-context when running at EL2. This
means the processor cannot speculate memory accesses using the registers
associated to that regime.
An isb() is only needed if Xen is going to use the translation regime
before returning to the guest (exception returns will
Only {A,F,I}MO are necessary to receive interrupts until a guest vCPU is
loaded.
The rest have no effect on Xen and it is better to avoid setting them.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Fix typo
-
A follow-up patch will need to generate the VTTBR in a few places.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Andrii's and Stefano's reviewed-by
---
xen/arch/arm/p2m.c | 7 ++-
1 file changed, 6
Signed-off-by: Julien Grall
---
xen/arch/arm/cpuerrata.c | 10 ++
xen/arch/arm/p2m.c | 2 ++
2 files changed, 12 insertions(+)
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 4431b244fd..727c67451d 100644
--- a/xen/arch/arm/cpuerrata.c
+++
A follow-up patch will require to allocate the root page-table without
having a domain in hand.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Andrii's and Stefano's reviewed-by
---
xen/arch/arm/p2m.c | 16
>>> On 28.01.19 at 12:40, wrote:
On 17.01.19 at 15:57, wrote:
>> @@ -83,3 +84,9 @@ subdir-$(CONFIG_UBSAN) += ubsan
>>
>> subdir-$(CONFIG_NEEDS_LIBELF) += libelf
>> subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
>> +
>> +config_data.c: ../.config
>> +( echo "const char xen_config_data[]
On 28/01/2019 09:51, Jan Beulich wrote:
> The increased number of messages (spec_ctrl.c:print_details()) within a
> certain time window made me notice some slowness of boot time screen
> output. Experimentally I've narrowed the time window to be from
> immediately after the early ucode update on
>>> On 17.01.19 at 15:57, wrote:
> @@ -83,3 +84,9 @@ subdir-$(CONFIG_UBSAN) += ubsan
>
> subdir-$(CONFIG_NEEDS_LIBELF) += libelf
> subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
> +
> +config_data.c: ../.config
> + ( echo "const char xen_config_data[] ="; \
> + cat $< | gzip |
1 - 100 of 121 matches
Mail list logo
