On Wed, Jun 21, 2017 at 03:32:39PM +0200, Marek Szyprowski wrote:
> linux-next
> was a side effect of that. I think that for now it can be dropped in favor
> of
> Christoph's tree. I can also do some review and help in maintainers work if
> needed, although I was recently busy with other stuff.
>
On Fri, Jun 23, Ankur Arora wrote:
> There was an earlier version of this patch by Konrad -- which takes
> care of the migration failure: https://patchwork.kernel.org/patch/6768031/
Thanks so much. That one actually works.
Olaf
signature.asc
Description: PGP signature
flight 111038 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111038/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 12 guest-start fail like 110899
test-xtf-amd64-amd64-2 46 xt
Hi Julien,
[...]
+
+/*
+ * As we have considered up to 2 MSBs of the GVA for mapping the
first
+ * level translation table, we need to make sure that we limit
the table
+ * offset that is is indexed by GVA<31-n:20> to max 10 bits to
avoid
>
Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes in v4:
(Take Jan's R-b with following changes.)
* Adjust error messages.
---
xen/arch/x86/cpu/mcheck/mce.c | 24 +++-
xen/include/public/arch-x86/xen-mca.h | 1 +
If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is present
in xl config, the LMCE capability will be exposed in guest MSR_IA32_MCG_CAP.
By default, LMCE is not exposed to guest so as to keep the backwards migration
compatibility.
Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
If option '-l' or '--lmce' is specified and the host supports LMCE,
xen-mceinj will inject LMCE to CPU specified by '-c' (or CPU0 if '-c'
is not present).
Signed-off-by: Haozhong Zhang
Acked-by: Wei Liu
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/tests/mce-test/tools/xen-mceinj.c | 50 +
Though XEN_MC_inject_v2 allows injecting MC# to specified CPUs, the
current xc_mca_op() does not use this feature and not provide an
interface to callers. This commit add a new xc_mca_op_inject_v2() that
receives a cpumap providing the set of target CPUs.
Signed-off-by: Haozhong Zhang
Acked-by: W
If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then allow guest
to read/write MSR_IA32_MCG_EXT_CTL.
Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/cpu/mcheck/vmce.c | 34 +-
xen/include
struct mc_telem_cpu_ctl is now used as the type of per-cpu variables,
rather than a globla variable shared by all CPUs, so some of its
comment do not apply any more.
Signed-off-by: Haozhong Zhang
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/cpu/mcheck/mctelem.c | 4 +---
1 file chang
v3 can be found at
https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg04118.html.
Changes in v4:
* Patch 1 is new and fixes some comment.
* Changes to MCE barriers in v3 Patch 1 "x86/mce: handle LMCE locally"
is moved out a separated v4 Patch 2. The rest of v3 Patch 1 becomes
Inject LMCE to guest if the host MCE is LMCE and the affected vcpu is
known. Otherwise, broadcast MCE to all vcpus on Intel host.
Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes in v4:
(Take Jan's R-b with following changes.)
* Change typ
A round of mce_softirq() may handle multiple deferred MCE's.
1/ If all of them are LMCE's, then mce_softirq() is called on one CPU
and should not wait for others.
2/ If at least one of them is non-local MCE, then mce_softirq()
should sync with other CPUs. mce_softirq() should check those
Add a 'nowait' argument to mce_barrier_{enter,exit}() to allow them
return immediately without waiting mce_barrier_{enter,exit}() on other
CPUs. This is useful when handling LMCE, where mce_barrier_{enter,exit}
are called only on one CPU.
Signed-off-by: Haozhong Zhang
---
Cc: Jan Beulich
Cc: And
If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then set LMCE and
LOCK bits in guest MSR_IA32_FEATURE_CONTROL. Intel SDM requires those
bits are set before SW can enable LMCE.
Signed-off-by: Haozhong Zhang
Reviewed-by: Kevin Tian
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Coop
Enable LMCE if it's supported by the host CPU. If Xen boot parameter
"mce_fb = 1" is present, LMCE will be disabled forcibly.
Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/cpu/mcheck/mce_intel.c | 46 +
On 26/06/17 02:02, Konrad Rzeszutek Wilk wrote:
On Sat, Jun 24, 2017 at 06:28:16PM +0100, Julien Grall wrote:
Hi Konrad,
On 06/23/2017 03:46 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jun 23, 2017 at 03:36:51PM +0100, Julien Grall wrote:
On 23/06/17 15:35, Konrad Rzeszutek Wilk wrote:
On F
And introduce vioapic_get_{mask/vector} in order to replace it's
usage.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v6:
- Constify domain parameter.
Changes since v5:
- New in this version.
---
xen/arch/x86/hvm/vioapic.c
On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote:
> I think we still need to do it. For example we have a bunch new "funky"
> cases.
I have no plan to do away with the selection - I just want a better
interface than the current one.
__
Achieve this by expanding pt_irq_create_bind in order to support
mapping interrupts of type PT_IRQ_TYPE_PCI to a PVH Dom0. GSIs bound
to Dom0 are always identity bound, which means the all the fields
inside of the u.pci sub-struct are ignored, and only the machine_irq
is actually used in order to d
Pending livepatch code wants to check if the vm_event wait queues
are active, and this is made harder by the fact that they were
previously only initialized some time after the domain was created,
in vm_event_enable(). This patch initializes the lists immediately
after xzalloc()ating the vm_event m
On Fri, Jun 23, 2017 at 9:03 AM, Roger Pau Monné wrote:
> On Fri, Jun 23, 2017 at 03:42:20AM -0400, Bruno Alvisio wrote:
>> This patch is the first attempt on adding live migration of instances with
>> local
>> storage to Xen. This patch just handles very restricted case of fully
>> virtualized H
On Sat, Jun 24, 2017 at 7:42 AM, Felix Schmoll
wrote:
> Hi,
>
> here a new version of my proposal for fuzzing the hypervisor. The original
> can be found here: [1].
>
> ==
> 1. Motivation and Description
> ==
> Fuzzing is a recent tre
This structure provides a convenient way of accessing contents of
VMX MSRs: every bit value is accessible by its name. Bit names match
existing Xen's definitions as close as possible.
The structure also contains the bitmap of available MSRs since not all
of them may be available on a particular H
The end goal of having VMX MSRs policy is to be able to manage
L1 VMX features. This patch series is the first part of this work.
There is no functional change to what L1 sees in VMX MSRs at this
point. But each domain will have a policy object which allows to
sensibly query what VMX features the d
Having a policy per domain allows to sensibly query what VMX features
the domain has, which unblocks some other nested virt work items.
For now, make policy for each domain equal to hvm_max_vmx_msr_policy.
In the future it should be possible to independently configure
the policy for each domain.
This is a debug patch I used when developing this series.
It's not intended for merging, I post it because it might be useful
to someone.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vmcs.c | 405
1 file changed, 405 insertions(+)
diff --git
1. Remove RDMSRs of VMX MSRs since all values are already available in
raw_vmx_msr_policy.
2. Replace bit operations involving VMX bitmasks with accessing VMX
features by name and using vmx_msr_available() where appropriate.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vmcs.c | 56
Add calculate_raw_policy() which fills raw_vmx_msr_policy (the actual
contents of H/W VMX MSRs) on the boot CPU. On secondary CPUs, this
function checks that contents of VMX MSRs match the boot CPU's contents.
Remove lesser version of same-contents-check from vmx_init_vmcs_config().
Signed-off-b
Currently, when nested virt is enabled, the set of L1 VMX features
is fixed and calculated by nvmx_msr_read_intercept() as an intersection
between the full set of Xen's supported L1 VMX features, the set of
actual H/W features and, for MSR_IA32_VMX_EPT_VPID_CAP, the set of
features that Xen uses.
On 06/26/2017 08:37 AM, 謝 東曄 wrote:
Xen Version:4.5.5
Guest OS(DomU OS):Ubuntu 14.04
Old kernel: 4.4.0
new recompile Kernel : 4.4.31
// Install DomU OS in image file
first, i use dd if=/dev/zero of=test.img bs=1M count=20480 to create 20G
empty image file.
then use xl create vm.cfg command to
On June 26, 2017 5:48:17 AM EDT, Razvan Cojocaru
wrote:
>Pending livepatch code wants to check if the vm_event wait queues
>are active, and this is made harder by the fact that they were
Hmm, it wants to? Is there an missing patch that hasn't been posted for this?
If you mean to post this _bef
On 06/26/2017 02:39 PM, Konrad Rzeszutek Wilk wrote:
> On June 26, 2017 5:48:17 AM EDT, Razvan Cojocaru
> wrote:
>> Pending livepatch code wants to check if the vm_event wait queues
>> are active, and this is made harder by the fact that they were
>
>
> Hmm, it wants to? Is there an missing pat
2b8eb379930 changed the type of i to be unsigned, but the inner loop
depends on it being a signed type.
Coverity-ID: 1413017
Signed-off-by: Wei Liu
---
Cc: Tim Deegan
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Tue, May 23, 2017 at 06:49:50AM -0600, Jan Beulich wrote:
> >>> On 27.04.17 at 16:35, wrote:
> > Add traps to each capability PCI_CAP_LIST_NEXT field in order to mask them
> > on
> > request.
> >
> > All capabilities from the device are fetched and stored in an internal list,
> > that's later
>>> Olaf Hering 06/26/17 8:47 AM >>>
>Am Mon, 26 Jun 2017 00:30:50 -0600
>schrieb "Jan Beulich" :
>
>> In the description you also talk about PIE, but you deal with PIC only here.
>> Is that intentional? If so, please say why in the description.
>
>Thats what the URL says. Unclear what the connec
c/s 2b8eb37 switched int i to being unsigned, but the undo logic on failure
relied in i being signed. As i being unsigned in still preforable, adjust the
undo logic to work with an unsigned i.
Coverity-ID: 1413017
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/mm.c | 2 +-
1
On 06/24/2017 12:01 AM, Gustavo A. R. Silva wrote:
Remove unnecessary variable mfn in function xen_foreach_remap_area() and,
refactor the code.
Variable mfn at line 518:mfn = xen_remap_buf.mfns[i];
is only being used to store a value to be passed as
an argument to the xen_update_mem_tables() fun
On 06/23/2017 02:47 PM, Marek Marczykowski-Górecki wrote:
Userspace application can do a hypercall through /dev/xen/privcmd, and
some for some hypercalls argument is a pointers to user-provided
structure. When SMAP is supported and enabled, hypervisor can't access.
So, lets allow it.
What about
On June 26, 2017 7:59:02 AM EDT, Andrew Cooper
wrote:
>c/s 2b8eb37 switched int i to being unsigned, but the undo logic on
>failure
>relied in i being signed. As i being unsigned in still preforable,
>adjust the
>undo logic to work with an unsigned i.
>
>Coverity-ID: 1413017
>Signed-off-by: Andr
On 26/06/17 12:39, Konrad Rzeszutek Wilk wrote:
> On June 26, 2017 5:48:17 AM EDT, Razvan Cojocaru
> wrote:
>> Pending livepatch code wants to check if the vm_event wait queues
>> are active, and this is made harder by the fact that they were
>
> Hmm, it wants to? Is there an missing patch that h
On 06/26/2017 03:14 PM, Andrew Cooper wrote:
> Razvan: I'd reword this to not mention livepatching. Simply having
> list_empty() working is a good enough reason alone.
Fair enough, I'll change the patch description as soon as we hear from
Tamas, so that I might address as many comments as possibl
flight 111043 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111043/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl 1 build-
On Mon, Jun 26, 2017 at 02:05:48PM +0200, Juergen Groß wrote:
> On 06/23/2017 02:47 PM, Marek Marczykowski-Górecki wrote:
> > Userspace application can do a hypercall through /dev/xen/privcmd, and
> > some for some hypercalls argument is a pointers to user-provided
> > structure. When SMAP is suppo
Userspace application can do a hypercall through /dev/xen/privcmd, and
some for some hypercalls argument is a pointers to user-provided
structure. When SMAP is supported and enabled, hypervisor can't access.
So, lets allow it.
The same applies to HYPERVISOR_dm_op, where additionally privcmd driver
On 06/26/2017 02:49 PM, Marek Marczykowski-Górecki wrote:
Userspace application can do a hypercall through /dev/xen/privcmd, and
some for some hypercalls argument is a pointers to user-provided
structure. When SMAP is supported and enabled, hypervisor can't access.
So, lets allow it.
The same ap
If the default compiler silently defaults to to -fPIC/-fPIE building
rombios fails:
ld -melf_i386 -s -r 32bitbios.o tcgbios/tcgbiosext.o util.o pmm.o -o
32bitbios_all.o
There are undefined symbols in the BIOS:
U _GLOBAL_OFFSET_TABLE_
make[10]: *** [Makefile:26: 32bitbios_all.o] Error
Am Mon, 26 Jun 2017 05:55:17 -0600
schrieb "Jan Beulich" :
> Unlike PIC, PIE was introduced later, yet might still be defaulted to. Hence
> it may be necessary to also deal with that, instead of just addressing one
> half.
There is now v2 which uses cc-option-add
> In the unstable staging tree
flight 71599 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71599/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-i386-sid-netboot-pvgrub 10 guest-start fail blocked in 71584
test-amd64-amd64-am
On 26/06/17 13:55, Olaf Hering wrote:
> If the default compiler silently defaults to to -fPIC/-fPIE building
> rombios fails:
>
> ld -melf_i386 -s -r 32bitbios.o tcgbios/tcgbiosext.o util.o pmm.o -o
> 32bitbios_all.o
> There are undefined symbols in the BIOS:
> U _GLOBAL_OFFSET_TABLE_
Hi,
On 12/06/17 17:59, Julien Grall wrote:
Hi Jan,
On 12/06/17 16:27, Jan Beulich wrote:
On 12.06.17 at 17:11, wrote:
We place the trampoline no lower than at 256k, so we have ample space
to read the MBRs of BIOS disks into an aligned buffer right below the
trampoline (not doing so has been
Nice write-up.
Overall this is in line with what we discussed, so I don't really have
more comments.
On Sat, Jun 24, 2017 at 08:42:50AM +0200, Felix Schmoll wrote:
[...]
> ==
> 3.3 Fuzzer
> ==
> The idea is to create some dictionary
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Marek Marczykowski-Górecki
> Sent: 26 June 2017 13:45
> To: Juergen Groß
> Cc: Andrew Cooper ; x...@kernel.org; linux-
> ker...@vger.kernel.org; sta...@vger.kernel.org; xen-
> de...@lists.xenproj
Hi,
On 23/06/17 10:31, Jan Beulich wrote:
On 23.06.17 at 11:24, wrote:
At 03:18 -0600 on 23 Jun (1498187924), Jan Beulich wrote:
How about:
- keep INVALID_MFN as an inline function call for most uses;
- #define INVALID_MFN_INITIALIZER { ~0UL } for when we need a
real constant initializer
This run is configured for baseline tests only.
flight 71598 xen-4.7-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71598/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-ins
On Mon, Jun 26, 2017 at 01:09:58PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> > Marek Marczykowski-Górecki
> > Sent: 26 June 2017 13:45
> > To: Juergen Groß
> > Cc: Andrew Cooper ; x...@kernel.org; linux-
>
> -Original Message-
> From: 'Marek Marczykowski-Górecki'
> [mailto:marma...@invisiblethingslab.com]
> Sent: 26 June 2017 14:22
> To: Paul Durrant
> Cc: Juergen Groß ; Andrew Cooper
> ; x...@kernel.org; linux-
> ker...@vger.kernel.org; sta...@vger.kernel.org; xen-
> de...@lists.xenproject.
On Mon, Jun 26, 2017 at 12:59:02PM +0100, Andrew Cooper wrote:
> c/s 2b8eb37 switched int i to being unsigned, but the undo logic on failure
> relied in i being signed. As i being unsigned in still preforable, adjust the
> undo logic to work with an unsigned i.
>
> Coverity-ID: 1413017
> Signed-o
gcc7 generates a call to __udivmoddi4 ...
stubdom/mini-os-x86_32-grub/mini-os.o: In function `_strtoll_r':
stubdom/newlib-x86_32/i686-xen-elf/newlib/libc/stdlib/../../../../../newlib-1.16.0/newlib/libc/stdlib/strtoll_r.c:110:
undefined reference to `__udivmoddi4'
make[2]: *** [Makefile:167: stubd
flight 111045 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111045/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 10 debian-di-installfail REGR. vs. 106835
Regre
On 26/06/17 14:00, Andrew Cooper wrote:
> On 26/06/17 13:55, Olaf Hering wrote:
>> If the default compiler silently defaults to to -fPIC/-fPIE building
>> rombios fails:
>>
>> ld -melf_i386 -s -r 32bitbios.o tcgbios/tcgbiosext.o util.o pmm.o -o
>> 32bitbios_all.o
>> There are undefined symbols i
On Tue, May 23, 2017 at 06:52:42AM -0600, Jan Beulich wrote:
> >>> On 27.04.17 at 16:35, wrote:
> > +#define REGISTER_VPCI_INIT(f, p)\
> > + static const struct vpci_register_init\
> > + x##_entry __used_
On Mon, Jun 26, 2017 at 3:48 AM, Razvan Cojocaru
wrote:
> Pending livepatch code wants to check if the vm_event wait queues
> are active, and this is made harder by the fact that they were
> previously only initialized some time after the domain was created,
> in vm_event_enable(). This patch init
On 26/06/17 15:52, Tamas K Lengyel wrote:
> On Mon, Jun 26, 2017 at 3:48 AM, Razvan Cojocaru
> wrote:
>> Pending livepatch code wants to check if the vm_event wait queues
>> are active, and this is made harder by the fact that they were
>> previously only initialized some time after the domain was
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 26 June 2017 14:04
> To: Jan Beulich
> Cc: Andrew Cooper ; Paul Durrant
> ; xen-devel ;
> Lars Kurth
> Subject: Re: [PATCH] x86/boot: re-arrange how/when we do disk I/O
>
> Hi,
>
> On 12/06/17 17:59, Julien
Xen Live Patching has been available as tech preview feature since Xen
4.7 and has now had a couple of releases to stabilize. Xen Live patching
has been used by multiple vendors to fix several real-world security
issues without any severe bugs encountered. Additionally, there are now
tests in OSSTe
flight 111067 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111067/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 578dbd52b70061fd3442dc5b050479e4f13b9585
baseline version:
ovmf 16bad1fbaf897ecd93fb5
On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote:
> Normally the __p4d() macro would be used and that would be ok whether
> CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the
> paravirt ops path I have to use native_make_p4d().
So __p4d is in !CONFIG_PARAVIRT path.
On Mon, Jun 26, 2017 at 9:09 AM, Andrew Cooper
wrote:
> On 26/06/17 15:52, Tamas K Lengyel wrote:
>> On Mon, Jun 26, 2017 at 3:48 AM, Razvan Cojocaru
>> wrote:
>>> Pending livepatch code wants to check if the vm_event wait queues
>>> are active, and this is made harder by the fact that they were
Factor out pv_trap_init and call it at the beginning of trap_init. We
then need to tune the code to generate stub handlers in entry.S. Take
the chance to tune init_irq_data so that 0x80 and 0x82 can be used in
!CONFIG_PV case.
While at it, fix some coding style issues in init_irq_data and replace
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/callback.c | 47 ++
xen/arch/x86/x86_64/compat/traps.c | 44 ---
2 files changed, 47 insertions(+), 44 deletions(-)
diff --git a/xen/arch/x86/pv/callback.c b/xen/arch/x86/pv/cal
Since ARM doesn't need do_nmi_op, move the hypercall handler from
common/kernel.c to pv/callback.c. Drop the stubs in ARM. Delete the
common and ARM nmi.h and adjust header inclusions in various files.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Stefano Stabellini
Cc: Juli
Take the chance to change v to curr.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/Makefile| 1 +
xen/arch/x86/pv/callback.c | 183
xen/arch/x86/x86_64/traps.c | 148 ---
3 files changed, 184 insertions(+), 148 dele
Take the chance to change v to curr.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/callback.c | 142
xen/arch/x86/x86_64/compat/traps.c | 143 -
2 files changed, 142 insertions(+), 143 deletions(-)
diff --git a/xen/ar
That hypercall is used to set guest callbacks for traps.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/callback.c | 50 ++
xen/arch/x86/traps.c | 50 --
2 files changed, 50 insertions(+), 50 deletions(-)
Signed-off-by: Wei Liu
---
xen/arch/x86/x86_64/compat/traps.c | 15 ---
xen/arch/x86/x86_64/traps.c| 2 --
2 files changed, 17 deletions(-)
delete mode 100644 xen/arch/x86/x86_64/compat/traps.c
diff --git a/xen/arch/x86/x86_64/compat/traps.c
b/xen/arch/x86/x86_64/compat/tr
Rename it to pv_raise_interrupt. Simplify the code by using the vcpu
structure already at hand in the caller.
Signed-off-by: Wei Liu
---
xen/arch/x86/traps.c | 13 -
xen/include/asm-x86/pv/traps.h | 8
xen/include/asm-x86/traps.h| 9 -
3 files change
There is only one caller for that function. Simplify the function,
move it close to the caller and rename it.
Signed-off-by: Wei Liu
---
xen/arch/x86/cpu/mcheck/vmce.c | 11 ++-
xen/arch/x86/traps.c | 18 --
xen/include/asm-x86/traps.h| 8
3 files
This series can also be found on my xenbits/xen.git wip.move-traps-v5
Wei Liu (13):
x86: move callback_op code to pv/callback.c
x86: move the compat callback ops next to the non-compat variant
x86: move do_set_trap_table to pv/callback.c
x86: move compat_set_trap_table along side the non-c
On 6/26/2017 10:45 AM, Borislav Petkov wrote:
On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote:
Normally the __p4d() macro would be used and that would be ok whether
CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the
paravirt ops path I have to use native_make_p4d(
CONFIG_BOOTPARAM_HOTPLUG_CPU0 allows to offline CPU0 but Xen HVM guests
BUG() in xen_teardown_timer(). Remove the BUG_ON(), this is probably a
leftover from ancient times when CPU0 hotplug was impossible, it works
just fine for HVM.
Signed-off-by: Vitaly Kuznetsov
---
- CPU0 hotplug is currently
On 26/06/17 16:36, Ross Lagerwall wrote:
> Xen Live Patching has been available as tech preview feature since Xen
> 4.7 and has now had a couple of releases to stabilize. Xen Live patching
> has been used by multiple vendors to fix several real-world security
> issues without any severe bugs encoun
On 26/06/17 17:28, Wei Liu wrote:
> Take the chance to change v to curr.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 111075 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111075/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 13 mig
Make register_guest_nmi_callback return int and make
unregister_guest_nmi_callback void. Adjust the callers where
necessary.
Signed-off-by: Wei Liu
---
Can be squashed into previous patch.
---
xen/arch/x86/pv/callback.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
d
Move these helper functions along side their users. Now all users of
these functions are within the same file, make them static.
Take the chance to change v to curr and remove some unneeded
parentheses.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/callback.c | 37 +
Those functions must be moved at the same time. Also move softirq_trap
because it is only used there.
Fix some coding style issues while moving code.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 104
xen/arch/x86/traps.c| 88
Signed-off-by: Wei Liu
---
xen/include/asm-x86/traps.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/include/asm-x86/traps.h b/xen/include/asm-x86/traps.h
index 8d903ec91b..bed25290d7 100644
--- a/xen/include/asm-x86/traps.h
+++ b/xen/include/asm-x86/traps.h
@@ -19,8 +19,6 @@
#ifndef
On 26/06/17 17:39, Andrew Cooper wrote:
>> * Bugs which allow a guest to prevent the application of a livepatch:
>> A guest should not be able to prevent the application of a live
>> patch. If an unprivileged guest can prevent the application of a
>> live patch, it shall be treated as a
On 06/26/2017 05:39 PM, Andrew Cooper wrote:
On 26/06/17 16:36, Ross Lagerwall wrote:
snip
* Unprivileged access to live patching operations:
Live patching operations should only be accessible to privileged
guests and it shall be treated as a security issue if this is not
the cas
On 26/06/17 17:28, Wei Liu wrote:
> Take the chance to change v to curr.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
George Dunlap writes ("Re: [PATCH for-4.9] livepatch: Declare live patching as
a supported feature"):
> I agree that as long as the patch can be applied after "xl pause", then
> the domain cannot be said to be preventing the application of the
> livepatch. But if either 'xl pause' doesn't work, o
On 26/06/17 17:28, Wei Liu wrote:
> That hypercall is used to set guest callbacks for traps.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 26/06/17 17:28, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 26/06/17 17:28, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 26/06/17 17:28, Wei Liu wrote:
> There is only one caller for that function. Simplify the function,
> move it close to the caller and rename it.
>
> Signed-off-by: Wei Liu
Good improvement. In principle, Reviewed-by: Andrew Cooper
, although...
> ---
> xen/arch/x86/cpu/mcheck/vmce.c | 11 ++
On 26/06/17 16:36, Ross Lagerwall wrote:
> Xen Live Patching has been available as tech preview feature since Xen
> 4.7 and has now had a couple of releases to stabilize. Xen Live patching
> has been used by multiple vendors to fix several real-world security
> issues without any severe bugs encoun
On 26/06/17 17:50, Ross Lagerwall wrote:
> On 06/26/2017 05:39 PM, Andrew Cooper wrote:
>> On 26/06/17 16:36, Ross Lagerwall wrote:
>>
>>>
>>> * Bugs which allow a guest to prevent the application of a livepatch:
>>> A guest should not be able to prevent the application of a live
>>> patc
On 26/06/17 17:50, George Dunlap wrote:
> On 26/06/17 17:39, Andrew Cooper wrote:
>>> * Bugs which allow a guest to prevent the application of a livepatch:
>>> A guest should not be able to prevent the application of a live
>>> patch. If an unprivileged guest can prevent the application of
flight 111049 qemu-upstream-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111049/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl
1 - 100 of 128 matches
Mail list logo