On 27.08.2019 18:04, Andrew Cooper wrote:
On 01/07/2019 12:58, Jan Beulich wrote:
@@ -9896,6 +9902,32 @@ x86_emulate(
: "0" ((uint32_t)src.val), "rm" (_regs.edx) );
break;
+case X86EMUL_OPC_66(0x0f38, 0xf8): /* movdir64b r,m512 */
+vcpu_
flight 140692 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140692/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
140598
Tests which did not
flight 140688 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140688/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139698
Tests which are faili
On 27/08/2019, 17:54, "Stefano Stabellini" wrote:
On Tue, 27 Aug 2019, Lars Kurth wrote:
> On 27/08/2019, 10:33, "Ian Jackson" wrote:
>
> Lars Kurth writes ("Re: [Xen-devel] [RFC] Code of Conduct"):
> > I did raise the issue of a cross-project support network, whi
Hi Robin,
> Subject: Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> On 09/07/2019 09:22, Peng Fan wrote:
> > arm64 shares some code under arch/arm/xen, including mm.c.
> > However ZONE_DMA is removed by commit
> > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > So to ARM64, n
flight 140683 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140683/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-build fail in 140650 REGR. vs. 139936
test-amd64-amd64-xl-q
Just wanted to give this a quick followup... Did this end up
progressing?
On Fri, Aug 16, 2019 at 3:37 PM, Steven Haigh wrote:
On 2019-08-16 15:25, Steven Haigh wrote:
On 2019-08-16 05:05, YOUNG, MICHAEL A. wrote:
On Thu, 15 Aug 2019, Steven Haigh wrote:
Having a bit of a look here
My
On Tue, 27 Aug 2019, Lars Kurth wrote:
> On 27/08/2019, 10:33, "Ian Jackson" wrote:
>
> Lars Kurth writes ("Re: [Xen-devel] [RFC] Code of Conduct"):
> > I did raise the issue of a cross-project support network, which has not
> yet been on the agenda. I will be hooked into this process.
flight 140727 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140727/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 140677 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140677/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 139876
Tests which are fa
flight 140676 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140676/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-xl-
On Wed, 14 Aug 2019, Volodymyr Babchuk wrote:
> Hi Julien,
>
> Julien Grall writes:
>
> > Commit af156ff085 "xen/arm: types: Specify the zero padding in the
> > definition of PRIregister" moved the zero padding within the definition
> > of PRIregister.
> >
> > However, some of the users still had
On Tue, 27 Aug 2019, Julien Grall wrote:
> Hi,
>
> On 27/08/2019 18:33, Andrii Anisov wrote:
> > From: Andrii Anisov
> >
> > In the commit af156ff0859c8d362a5706640614c9d10f62adf2, it
> > was left unattended HPFAR_EL2 register output. Now it is printed
> > with 1608 digits, what is way too wide
flight 140684 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140684/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 140559
build-amd64
On 27/08/2019 11:44, Andrew Cooper wrote:
>> I was also uncertain about the new cache_flush_permitted() instance -
>> generally I think it wouldn't be too bad if we allowed line flushes in
>> all cases, in which case the checks in the ->wbinvd_intercept() handlers
>> would suffice (as they did unti
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid guest-start/debianhvm.repeat
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.x
Lars Kurth writes ("Re: [Xen-devel] [RFC] Code of Conduct"):
> I did raise the issue of a cross-project support network, which has not yet
> been on the agenda. I will be hooked into this process.
> My gut feeling is that we are looking at 6-9 months before all of this is
> resolved. Maybe longer
On 27/08/2019 16:53, Jan Beulich wrote:
> On 27.08.2019 17:31, Andrew Cooper wrote:
>> On 01/07/2019 12:57, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -9124,6 +9126,48 @@ x86_emulate(
>>> ASSERT(!state->simd
Hi,
On 27/08/2019 18:33, Andrii Anisov wrote:
> From: Andrii Anisov
>
> In the commit af156ff0859c8d362a5706640614c9d10f62adf2, it
> was left unattended HPFAR_EL2 register output. Now it is printed
> with 1608 digits, what is way too wide even for the biggest
> monitors. So cleanup excessive pad
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v2] Allow get_maintainer.pl
/ add_maintainers.pl scripts to be called outside of xen.git"):
> On Fri, 23 Aug 2019, Lars Kurth wrote:
> > Hi all. I would like to get this resolved and was looking for
> > opinions. The thread is about enabling usag
On August 27, 2019 4:46:17 AM EDT, Pawel Wieczorkiewicz
wrote:
>By default, in the quiescing zone, a hotpatch payload is applied with
>apply_payload() and reverted with revert_payload() functions. Both of
>the functions receive the payload struct pointer as a parameter. The
>functions are also a
On 27/08/2019 16:08, Jan Beulich wrote:
> On 27.08.2019 16:47, Andrew Cooper wrote:
>> On 01/07/2019 12:56, Jan Beulich wrote:
>>> --- a/xen/arch/x86/pv/emul-priv-op.c
>>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>>> @@ -1121,7 +1121,7 @@ static int write_msr(unsigned int reg, u
>>> @@ -1130,6 +1130,8
From: Andrii Anisov
In the commit af156ff0859c8d362a5706640614c9d10f62adf2, it
was left unattended HPFAR_EL2 register output. Now it is printed
with 1608 digits, what is way too wide even for the biggest
monitors. So cleanup excessive paddings.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/tra
ilable in the Git repository at:
>
> https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git
> tags/pull-xen-20190827
>
> for you to fetch changes up to 705be570941b38cd1cbebc68f7f671ce7532ecb0:
>
> xen-bus: Avoid rewriting identi
flight 140710 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140710/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 01/07/2019 12:58, Jan Beulich wrote:
> Note that the ISA extensions document revision 035 doesn't specify
> exception behavior for ModRM.mod != 0b11; assuming #UD here.
This has moved into the main SDM now. These instructions don't make
sense with reg/reg encodings, so I expect that encoding s
On 27.08.2019 17:31, Andrew Cooper wrote:
On 01/07/2019 12:57, Jan Beulich wrote:
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -9124,6 +9126,48 @@ x86_emulate(
ASSERT(!state->simd_size);
break;
+case X86EMUL_OPC_66(0x0
On 13.08.2019 12:53, Andrew Cooper wrote:
This functionality is obsolete. It was introduced by c/s 41296317a31 into
Xend, but was never exposed in libxl.
Nothing limits this to PV guests, but it makes no sense for HVM guests.
Looking through the XenServer templates, this was used to work aroun
On 08/27/2019 04:38 PM, Andrew Cooper wrote:
... rather than leaving the user with no hint as to where to debug next.
Signed-off-by: Andrew Cooper
---
CC: Konrad Rzeszutek Wilk
CC: Ross Lagerwall
Reviewed-by: Ross Lagerwall
Thanks
___
Xen-devel
On August 27, 2019 11:38:39 AM EDT, Andrew Cooper
wrote:
>... rather than leaving the user with no hint as to where to debug
>next.
>
>Signed-off-by: Andrew Cooper
>---
>CC: Konrad Rzeszutek Wilk
Reviewed-by: Konrad Rzeszutek Wilk
>CC: Ross Lagerwall
>---
> livepatch-build | 2 +-
> 1 file c
flight 140670 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140670/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestore.2 fail REGR. vs. 139910
test-amd64-amd64-xl-
On 13.08.2019 12:53, Andrew Cooper wrote:
This functionality is obsolete. It was introduced by c/s 39407bed9c0 into
Xend, but never exposed in libxl.
This is good enough a reason I think (hope), while ...
While not explicitly limited to PV guests, this is PV-only by virtue of its
position in
... rather than leaving the user with no hint as to where to debug next.
Signed-off-by: Andrew Cooper
---
CC: Konrad Rzeszutek Wilk
CC: Ross Lagerwall
---
livepatch-build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/livepatch-build b/livepatch-build
index 7068faf..b198c9
On 01/07/2019 12:57, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -9124,6 +9126,48 @@ x86_emulate(
> ASSERT(!state->simd_size);
> break;
>
> +case X86EMUL_OPC_66(0x0f38, 0x82): /* invpcid reg,m128 */
On 23.08.2019 07:58, Tian, Kevin wrote:
From: Roger Pau Monne [mailto:roger@citrix.com]
Sent: Tuesday, August 20, 2019 11:38 PM
The level passed to ept_invalidate_emt corresponds to the EPT entry
passed as the mfn parameter, which is a pointer to an EPT page table,
hence the entries in tha
On 27.08.2019 16:59, Oleksandr wrote:
There was a preference to introduce callback in a separate patch [2]. Anyway,
shall I fold it?
Hmm, I disagree with Julien here. I don't think we should have unused
hooks in the tree, not even intermediately.
Jan
_
On 27.08.2019 16:47, Andrew Cooper wrote:
On 01/07/2019 12:56, Jan Beulich wrote:
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -1121,7 +1121,7 @@ static int write_msr(unsigned int reg, u
@@ -1130,6 +1130,8 @@ static int cache_op(enum x86emul_cache_o
*
Hi Jan
On 20.08.2019 20:09, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -240,6 +240,16 @@ struct iommu_ops {
int __must_check (*iotlb_flush_all)(struct domain *d);
int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
void (
On 01/07/2019 12:57, Jan Beulich wrote:
> --- a/xen/include/asm-x86/x86-defns.h
> +++ b/xen/include/asm-x86/x86-defns.h
> @@ -108,4 +108,12 @@
>*/
> #define X86_DR7_DEFAULT 0x0400 /* Default %dr7 value. */
>
> +/*
> + * Invalidation types for the INVPCID instruction.
> + */
>
On 01/07/2019 12:56, Jan Beulich wrote:
> The hook is already in use for INVLPGA as well. Rename the hook and add
> parameters. For the moment INVLPGA with a non-zero ASID remains
> unsupported, but the TODO item gets pushed into the actual hook handler.
>
> Signed-off-by: Jan Beulich
Reviewed-by
On 19.08.2019 15:42, Andrew Cooper wrote:
lmsw is an obsolete relic of the 286 processor - so much so that it even lacks
intercept assistance on AMD processors.
Use a plain mov to %cr0 which is easier to follow, certainly faster to
virtualise on AMD hardware, and almost certainly a faster microc
On 19.08.2019 15:42, Andrew Cooper wrote:
... to separate code from data. In particular, trampoline_realmode_entry's
write to trampoline_cpu_started clobbers the I-cache line containing
trampoline_protmode_entry, which won't be great for AP startup.
Reformat the comments for trampoline_gdt to r
On 19.08.2019 15:42, Andrew Cooper wrote:
gdt_boot_descr and gdt_48 disagree on how long trampoline_gdt is.
Introduce an end label and have the linker calculate the size, rather than
hard coding it.
Also, just as with c/s af292b41e9, there is no point forcing the CPU to set
Access bits. Fix al
On 01/07/2019 12:56, Jan Beulich wrote:
> Rev 035 of Intel's ISA extensions document does not state intercept
> behavior for the insn (I've been in-officially told that the distinction
unofficially.
> is going to be by exit qualification, as I would have assumed
> considering that this way it's s
On 14.08.2019 12:44, Andrew Cooper wrote:
Introduce a new ENDDATA() helper which sets type and size together.
Except this isn't very natural: Setting the size late is quite
common, to avoid the need for an "end" label. But the type would
better be set together with the label definition, i.e. by
On 14.08.2019 14:00, Wei Liu wrote:
On Wed, Aug 14, 2019 at 11:44:04AM +0100, Andrew Cooper wrote:
[...]
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 22dc795eea..35705441ff 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -56,6 +56
On 13.08.2019 14:01, Andrew Cooper wrote:
Clang-3.5 from Debian Jessie fails with:
smpboot.c:829:29: error: statement expression not allowed at file scope
BUILD_BUG_ON(sizeof(this_cpu(tss_page)) != PAGE_SIZE);
^
/local/xen.git/xen/include/asm/percp
On 12.08.2019 17:10, Andrew Cooper wrote:
mov/shr is easier to follow than shld, and doesn't have a merge dependency on
the previous value of %edx. Shorten the rest of the code by streamlining the
comments.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
In
On 12.08.2019 20:21, Andrew Cooper wrote:
This started off as "get rid of load_TR()" as identified in the TSS cleanup
series, and morphed slightly.
Andrew Cooper (3):
x86/suspend: Sanity check more properties in enter_state()
x86/desc: Move boot_gdtr into .rodata
x86/suspend: Simplify s
On 22.08.2019 08:51, Roger Pau Monne wrote:
The new format specifier is '%pp', and prints a pci_sbdf_t using the
seg:bus:dev.func format. Replace all SBDFs printed using
'%04x:%02x:%02x.%u' to use the new format specifier.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Chang
On 19.07.2019 14:25, Paul Durrant wrote:
When commit 3f8f1228 "x86/mm: add HYPERVISOR_memory_op to acquire guest
resources" introduced the concept of directly mapping some guest resources,
it was envisaged that the memory for some resources associated with a guest
may not actually be assigned to
When QEMU receives a xenstore watch event suggesting that the "state"
of the frontend changed, it records this in its own state but it also
re-write the value back into xenstore even so there were no change.
This triggers an unnecessary xenstore watch event which QEMU will
process again (and maybe
When a frontend wants to reset its state and the backend one, it
starts with setting "Closing", then waits for the backend (QEMU) to do
the same.
But when QEMU is setting "Closing" to its state, it triggers an event
(xenstore watch) that re-execute xen_device_backend_changed() and set
the backend
The xen_[rw]?mb() macros defined in ring.h can't be used and the fact
that there are gated behind __XEN_INTERFACE_VERSION__ means that it
needs to be defined somewhere. QEMU doesn't implement interfaces with
the Xen hypervisor so defining __XEN_INTERFACE_VERSION__ is pointless.
This leads to:
i
.git
tags/pull-xen-20190827
for you to fetch changes up to 705be570941b38cd1cbebc68f7f671ce7532ecb0:
xen-bus: Avoid rewriting identical values to xenstore (2019-08-27 14:18:28
+0100)
Xen queue
* Fixes for xen-bus and exit cleanu
From: Igor Druzhinin
Device model is supposed to destroy IOREQ server for itself.
Signed-off-by: Igor Druzhinin
Acked-by: Paul Durrant
Message-Id: <1564428563-1006-1-git-send-email-igor.druzhi...@citrix.com>
Signed-off-by: Anthony PERARD
---
hw/i386/xen/xen-hvm.c | 2 ++
1 file changed, 2 in
On 20.08.2019 20:09, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -240,6 +240,16 @@ struct iommu_ops {
int __must_check (*iotlb_flush_all)(struct domain *d);
int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
void (*dump_p2m_
On 20.08.2019 20:09, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -35,6 +35,18 @@
#define xzalloc_array(_type, _num) \
((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type), _num))
+/* Re-allocate space for a structure with a flexi
On 27/08/2019 11:44, Andrew Cooper wrote:
>> I was also uncertain about the new cache_flush_permitted() instance -
>> generally I think it wouldn't be too bad if we allowed line flushes in
>> all cases, in which case the checks in the ->wbinvd_intercept() handlers
>> would suffice (as they did unti
On 27.08.19 14:37, Andrew Cooper wrote:
On 27/08/2019 11:59, Juergen Gross wrote:
+static void *
+sched_idle_alloc_vdata(const struct scheduler *ops, struct vcpu *v,
+ void *dd)
+{
+/* Any non-NULL pointer is fine here. */
+return (void *)1UL;
As an observation, t
On 27/08/2019 11:59, Juergen Gross wrote:
> +static void *
> +sched_idle_alloc_vdata(const struct scheduler *ops, struct vcpu *v,
> + void *dd)
> +{
> +/* Any non-NULL pointer is fine here. */
> +return (void *)1UL;
As an observation, the vdata interface (and others,
On 09/07/2019 09:22, Peng Fan wrote:
arm64 shares some code under arch/arm/xen, including mm.c.
However ZONE_DMA is removed by commit
ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
So to ARM64, need use __GFP_DMA32.
Signed-off-by: Peng Fan
---
arch/arm/xen/mm.c | 2 +-
1 file change
On 27/08/2019 12:48, Igor Druzhinin wrote:
> Since guest resource management work it's now possible to have a page
> assigned to a domain without a valid M2P entry. Some pathes in the code
paths
> rely on the fact a GFN returned from mfn_to_gfn() for such a page
> is not valid as well, i.e. see a
Since guest resource management work it's now possible to have a page
assigned to a domain without a valid M2P entry. Some pathes in the code
rely on the fact a GFN returned from mfn_to_gfn() for such a page
is not valid as well, i.e. see arch_iommu_populate_page_table().
For systems without 512GB
Jan Beulich writes ("Re: [PATCH 2/3] build: allow picking the env values for
compiler variables"):
> On 20.08.2019 09:58, Roger Pau Monné wrote:
> > I don't have things 'left' in the environment, neither have most build
> > systems AFAIK. I do have things set that I want the build to
> > acknowle
Instead of having a full blown scheduler running for the free cpus
add a very minimalistic scheduler for that purpose only ever scheduling
the related idle vcpu. This has the big advantage of not needing any
per-cpu, per-domain or per-scheduling unit data for free cpus and in
turn simplifying movin
Simplify cpupool initialization by populating cpupool0 with cpus only
after all cpus are up. This avoids having to call the cpu notifier
directly for cpu 0.
With that in place there is no need to create cpupool0 earlier, so
do that just before assigning the cpus. Initialize free cpus with all
onli
These three patches have been carved out from my core scheduling series
as they are sufficiently independent to be applied even without the big
series.
Without this little series there are messages like the following to be
seen on the console when booting with smt=0:
(XEN) Adding cpu 1 to runqueu
Today a cpu which is removed from the system is taken directly from
Pool0 to the offline state. This will conflict with the new idle
scheduler, so remove it from Pool0 first. Additionally accept removing
a free cpu instead of requiring it to be in Pool0.
For the resume failed case we need to call
flight 140663 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140663/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
test-amd64-i386-qemu
On 01/07/2019 12:56, Jan Beulich wrote:
> The hook is already in use for other purposes, and emulating e.g.
> CLFLUSH by issuing WBINVD is, well, not very nice. Rename the hook and
> add parameters. Use lighter weight flushing insns when possible in
> hvmemul_cache_op().
>
> hvmemul_cache_op() trea
> -Original Message-
> From: Anthony PERARD
> Sent: 23 August 2019 11:16
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; Stefano Stabellini
> ; Paul
> Durrant ; xen-devel@lists.xenproject.org
> Subject: [PATCH v2 2/2] xen-bus: Avoid rewriting identical values to xenstore
>
> When QEMU
You need to find someone who is interested in Xen on 32-bit ARM, and
who knows this code - and therefore what impact your change causes.
That isn't me, sorry.
On Tue, Aug 27, 2019 at 09:27:53AM +, Peng Fan wrote:
> Ping again..
>
> +Julien
>
> > Subject: RE: [PATCH] arm: xen: mm: use __GPF_D
> -Original Message-
> From: Anthony PERARD
> Sent: 23 August 2019 11:16
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; qemu-sta...@nongnu.org;
> Stefano Stabellini
> ; Paul Durrant ;
> xen-devel@lists.xenproject.org
> Subject: [PATCH v2 1/2] xen-bus: Fix backend state transition on
> On 19.08.2019 17:24, David Woodhouse wrote:
>> On Mon, 2019-08-12 at 11:55 +0200, Jan Beulich wrote:
>>> On 09.08.2019 17:02, David Woodhouse wrote:
From: David Woodhouse
In preparation for splitting the boot and permanent trampolines from
each other. Some of these will cha
Ping again..
+Julien
> Subject: RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> Hi Russell, Stefano
>
> > Subject: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> Any comments?
>
> >
> > arm64 shares some code under arch/arm/xen, including mm.c.
> > However ZONE_DMA is removed by
> On 19.08.2019 17:25, David Woodhouse wrote:
>> On Mon, 2019-08-12 at 12:24 +0200, Jan Beulich wrote:
>>> On 09.08.2019 17:02, David Woodhouse wrote:
@@ -227,7 +231,7 @@ start64:
.word 0
idt_48: .word 0, 0, 0 # base = limit = 0
.word 0
-gdt_48
On 20.08.2019 09:58, Roger Pau Monné wrote:
On Mon, Jul 29, 2019 at 03:35:36PM +, Jan Beulich wrote:
On 26.07.2019 15:33, Roger Pau Monne wrote:
Don't force the usage of the hardcoded compiler values if those are
already set on the environment. This allows the Xen build system to
correctly
> On 19.08.2019 17:25, David Woodhouse wrote:
>> On Mon, 2019-08-12 at 12:55 +0200, Jan Beulich wrote:
>>> On 09.08.2019 17:02, David Woodhouse wrote:
@@ -97,7 +100,7 @@ GLOBAL(trampoline_realmode_entry)
cld
cli
lidttrampsym(idt_48)
-
On 19.08.2019 17:25, David Woodhouse wrote:
On Mon, 2019-08-12 at 12:55 +0200, Jan Beulich wrote:
On 09.08.2019 17:02, David Woodhouse wrote:
@@ -97,7 +100,7 @@ GLOBAL(trampoline_realmode_entry)
cld
cli
lidttrampsym(idt_48)
-lgdttrampsym(gdt_48)
+
On 19.08.2019 17:25, David Woodhouse wrote:
On Mon, 2019-08-12 at 12:24 +0200, Jan Beulich wrote:
On 09.08.2019 17:02, David Woodhouse wrote:
@@ -227,7 +231,7 @@ start64:
.word 0
idt_48: .word 0, 0, 0 # base = limit = 0
.word 0
-gdt_48: .word 6*8-1
+gdt_48: .word
On 19.08.2019 17:24, David Woodhouse wrote:
On Mon, 2019-08-12 at 11:55 +0200, Jan Beulich wrote:
On 09.08.2019 17:02, David Woodhouse wrote:
From: David Woodhouse
In preparation for splitting the boot and permanent trampolines from
each other. Some of these will change back, but most are boo
Livepatch only tracks an entire payload applied/reverted state. But,
with an option to supply the apply_payload() and/or revert_payload()
functions as optional hooks, it becomes possible to intermix the
execution of the original apply_payload()/revert_payload() functions
with their dynamically supp
This series introduces new features to the livepatch functionality as
briefly discussed during Xen Developer Summit 2019: [a] and [b].
It also provides a few fixes and some small improvements.
Main changes in v2:
- added new features to livepatch documentation
- added livepatch tests
- enabled Arm
With default implementation the ELF_LIVEPATCH_FUNC section containing
all functions to be replaced or added must be part of the hotpatch
payload, otherwise the payload is rejected (with -EINVAL).
However, with the extended hooks implementation, a hotpatch may be
constructed of only hooks to perfor
This is the initial implementation of the expectations enhancement
to improve inline asm hotpatching.
Expectations are designed as optional feature, since the main use of
them is planned for inline asm hotpatching. The flag enabled allows
to control the expectation state.
Each expectation has data
Extend the XC python bindings library to support also all common
livepatch operations and actions.
Add the python bindings for the following operations:
- status (pyxc_livepatch_status):
Requires a payload name as an input.
Returns a status dict containing a state string and a return code
in
By default, in the quiescing zone, a hotpatch payload is applied with
apply_payload() and reverted with revert_payload() functions. Both of
the functions receive the payload struct pointer as a parameter. The
functions are also a place where standard 'load' and 'unload' module
hooks are executed.
This is an implementation of 4 new livepatch module vetoing hooks,
that can be optionally supplied along with modules.
Hooks that currently exists in the livepatch mechanism aren't agile
enough and have various limitations:
* run only from within a quiescing zone
* cannot conditionally prevent appl
Extend the livepatch list operation to fetch also payloads' metadata.
This is achieved by extending the sysctl list interface with 2 extra
guest handles:
* metadata - an array of arbitrary size strings
* metadata_len - an array of metadata strings' lengths (uin32_t each)
Payloads' metadata is
The payloads' name strings can be of arbitrary size (typically small
with an upper bound of XEN_LIVEPATCH_NAME_SIZE).
Current implementation of the list operation interface allows to copy
names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of its actual
size and enforces space allocation require
The payload structure will be used by the new hooks implementation and
therefore its definition has to be exported via the livepatch_payload
header.
The new hooks will make use of the payload structure fields and the
hooks' pointers will also be defined in the payload structure, so
the structure al
By default Livepatch enforces the following buildid-based dependency
chain between hotpatch modules:
1) first module depends on given hypervisor buildid
2) every consecutive module depends on previous module's buildid
This way proper hotpatch stack order is maintained and enforced.
While it is
Having detailed hotpatch metadata helps to properly identify module's
origin and version. It also allows to keep track of the history of
hotpatch loads in the system (at least within dmesg buffer size
limits).
The hotpatch metadata are embedded in a form of .modinfo section.
Each such section cont
This change is part of a independant stacked hotpatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.
In order to prevent (up)loading any hotpatches built for different
hypervisor version as indicated by the Xen Bu
On 21.08.2019 16:04, David Woodhouse wrote:
On Mon, 2019-08-12 at 11:10 +0200, Jan Beulich wrote:
On 09.08.2019 17:01, David Woodhouse wrote:
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -735,7 +735,17 @@ trampoline_setup:
/* Switch to low-memory stack which lives
flight 140659 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140659/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 140571
test-amd64-amd64-xl
On 15.08.2019 16:24, Andrew Cooper wrote:
On 01/07/2019 12:47, Jan Beulich wrote:
On top of the AVX512 series I'd like to put out for review/discussion
1: generalize wbinvd() hook
2: support WBNOINVD
3: generalize invlpg() hook
4: move INVPCID_TYPE_* to x86-defns.h
5: support INVPCID
6: support
On 20.08.2019 22:11, Andrew Cooper wrote:
On 30/07/2019 15:54, Jan Beulich wrote:
@@ -622,14 +622,22 @@ static void *hvmemul_map_linear_addr(
}
if ( p2mt == p2m_ioreq_server )
-{
-err = NULL;
goto out;
-
> -Original Message-
> From: Andrew Cooper
> Sent: 23 August 2019 13:26
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu ;
> Konrad Rzeszutek Wilk
> ; George Dunlap ; Tim
> (Xen.org) ; Ian
> Jackson ; Julien Grall ; Jan
> Beulich
> ; Roger Pau Monne
1 - 100 of 105 matches
Mail list logo
