>>> On 23.01.18 at 16:22, wrote:
> Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has
> been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so
> that it is only defined when XC_WANT_COMPAT_DEVICEMODEL_API is set and
> have it call the new dmop. Leave the definitio
>>> On 23.01.18 at 16:22, wrote:
> Provide XEN_DMOP_relocate_memory, a limited version of
> XENMEM_add_to_physmap to allow a deprivileged QEMU to move VRAM when a
> guest programs its BAR. It is equivalent to XENMEM_add_to_physmap with
> space == XENMAPSPACE_gmfn_range.
>
> Signed-off-by: Ross La
This is a note to let you know that I've just added the patch titled
x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
to the 4.4-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
This is a note to let you know that I've just added the patch titled
x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
to the 3.18-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 th
This is a note to let you know that I've just added the patch titled
x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
to the 4.9-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
On Tue, Jan 23, 2018 at 04:47:51PM -0800, Stefano Stabellini wrote:
> On Tue, 23 Jan 2018, Jan Beulich wrote:
> > >>> On 23.01.18 at 01:41, wrote:
> > > On 23/01/2018 00:38, Stefano Stabellini wrote:
> > >> On Tue, 23 Jan 2018, Andrew Cooper wrote:
> > >>> On 22/01/2018 23:48, Stefano Stabellini w
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 24 January 2018 08:10
> To: Ross Lagerwall
> Cc: Andrew Cooper ; Paul Durrant
> ; Wei Liu ; George Dunlap
> ; Ian Jackson ;
> Stefano Stabellini ; xen-de...@lists.xen.org; Konrad
> Rzeszutek Wilk ; Tim (Xen.org)
>
Hi all,
since we are participating the first time to GSoC, we are happy to
receive any feedback from you regarding our proposed Unikraft projects!
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Unikraft
Thanks,
Simon
On 23.01.2018 10:16, Lars Kurth wrote:
Hi all,
just a quick
Hi all,
since we are participating the first time to GSoC, we are happy to
receive any feedback from you regarding our proposed Unikraft projects!
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Unikraft
Thanks,
Simon
On 23.01.2018 10:16, Lars Kurth wrote:
Hi all,
just a quick
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
Changes since v1:
- s/gmake/make/.
- Fix gcov section to mention CONFIG_COVERAGE instead of CONFIG_GCOV.
Introduce the functionality in order to fill the hooks of the
cov_sysctl_ops struct. Note that the functionality is still not wired
into the build system.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad R
Hello,
The following patch series enables LLVM coverage support for the Xen
hypervisor. A sample coverage report obtained after booting a PVHv2 Dom0
can be found at:
http://xenbits.xen.org/people/royger/xen_profile/
I know the time is not the most appropriate given all the security work
going on
llvm coverage support seems to disable some of the optimizations
needed in order to compile xsm, and the end result is that references
to __xsm_action_mismatch_detected are left in the object files.
Since coverage support cannot be used in production, introduce
__xsm_action_mismatch_detected for l
So that other implementations of the sysctl can be added.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
Changes since v2:
- Add
Change gcov to cov (for internal interfaces) or coverage (for the
public ones).
Signed-off-by: Roger Pau Monné
Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Ian Jackson
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano
flight 118285 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118285/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win10-i386 6 xen-install fail REGR. vs. 118170
test-xtf-amd64-
So it can be used by both gcc and clang. Just add the Kconfig option
and modify the makefiles so the llvm coverage specific code can be
added in a follow up patch.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
It will contain the generic implementation of sysctl_cov_op, which
will be shared between all the coverage implementations.
Signed-off-by: Roger Pau Monné
Reviewed-by: Konrad Rzeszutek Wilk
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc:
Or else the watchdog triggers on boxes with a huge number of CPUs
Signed-off-by: Roger Pau Monné
Reported-by: Simon Crowe
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/acpi/cpu_idle.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/a
flight 118300 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118300/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 1c8627d2a102274f8afeb9dc548100a60077fc8d
baseline version:
xen 3fa1
On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky
wrote:
> On 01/18/2018 05:33 AM, Wei Liu wrote:
>> On Thu, Jan 18, 2018 at 11:31:32AM +0100, Juergen Gross wrote:
>>> Wei,
>>>
>>> On 01/12/17 15:14, Juergen Gross wrote:
Instead of locating the RSDP table below 1MB put it just below 4GB
l
On 24/01/18 10:14, Roger Pau Monne wrote:
> Or else the watchdog triggers on boxes with a huge number of CPUs
>
> Signed-off-by: Roger Pau Monné
> Reported-by: Simon Crowe
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.
On 24/01/18 00:47, Stefano Stabellini wrote:
> On Tue, 23 Jan 2018, Jan Beulich wrote:
> On 23.01.18 at 01:41, wrote:
>>> On 23/01/2018 00:38, Stefano Stabellini wrote:
On Tue, 23 Jan 2018, Andrew Cooper wrote:
> On 22/01/2018 23:48, Stefano Stabellini wrote:
>> Hi all,
>>
>>>
Looks good to me. The difficulties are all ‘medium’ though. Perhaps break up
the “new execution targets” into medium/hard for the various backends? For
example, Xen/ARM is probably easier than bare metal ARM, and I imagine HyperV
is quite complex due to the extra coordination code that is requi
On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote:
> On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky
> wrote:
> > On 01/18/2018 05:33 AM, Wei Liu wrote:
> >> On Thu, Jan 18, 2018 at 11:31:32AM +0100, Juergen Gross wrote:
> >>> Wei,
> >>>
> >>> On 01/12/17 15:14, Juergen Gross wrote:
>
The function replace_va_mapping() has multiple issues:
* It uses linear addresses, not virtual addresses. Fix its name.
* Guest pagetables are allocated from the domheap not the xenheap, so need
map_domain_page() to safely access.
* put_page_and_type() should only apply to present mappings.
On 10/20/2017 02:37 PM, Ian Jackson wrote:
Anthony PERARD writes ("Re: [PATCH v5 0/8] xen: xen-domid-restrict
improvements"):
The patches in this v5 appear to be the same the one from the patch
series v4.
Erk, so they are.
I'll post a v5.1 in reply to this email.
What's the status of this
>>> On 04.01.18 at 21:21, wrote:
> Windows is the only OS which pages out kernel datastructures, so chances are
> good that this is a vestigial remnant of the PV Windows XP experiment.
> Furthermore the implementation is incomplete; it only functions for a present
> => not-present transition, rath
On Wed, Jan 24, 2018 at 10:01:19AM +, Roger Pau Monne wrote:
> Change gcov to cov (for internal interfaces) or coverage (for the
> public ones).
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Konrad Rzeszutek Wilk
> Acked-by: Ian Jackson
Acked-by: Wei Liu
_
On Wed, Jan 24, 2018 at 11:00:05AM +, Andrew Cooper wrote:
> The function replace_va_mapping() has multiple issues:
> * It uses linear addresses, not virtual addresses. Fix its name.
> * Guest pagetables are allocated from the domheap not the xenheap, so need
>map_domain_page() to safely
On Wed, Jan 24, 2018 at 10:01:20AM +, Roger Pau Monne wrote:
> So that other implementations of the sysctl can be added.
>
> Signed-off-by: Roger Pau Monné
> Acked-by: Jan Beulich
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenp
On Wed, Jan 24, 2018 at 10:01:21AM +, Roger Pau Monne wrote:
> It will contain the generic implementation of sysctl_cov_op, which
> will be shared between all the coverage implementations.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Wei Liu
__
On Wed, Jan 24, 2018 at 10:01:22AM +, Roger Pau Monne wrote:
> So it can be used by both gcc and clang. Just add the Kconfig option
> and modify the makefiles so the llvm coverage specific code can be
> added in a follow up patch.
>
> Signed-off-by: Roger Pau Monné
> diff --git a/xen/Rules.mk
On Wed, Jan 24, 2018 at 10:01:23AM +, Roger Pau Monne wrote:
> Introduce the functionality in order to fill the hooks of the
> cov_sysctl_ops struct. Note that the functionality is still not wired
> into the build system.
>
> Signed-off-by: Roger Pau Monné
> Acked-by: Jan Beulich
Acked-by:
On Wed, Jan 24, 2018 at 10:01:25AM +, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Roger Pau Monne writes ("[PATCH v3 4/7] kconfig/gcov: rename to coverage"):
> So it can be used by both gcc and clang. Just add the Kconfig option
> and modify the makefiles so the llvm coverage specific code can be
> added in a follow up patch.
...
> diff --git a/xen/common/sysctl.c b/xen/common/s
Ross Lagerwall writes ("Re: [PATCH v5 0/8] xen: xen-domid-restrict
improvements"):
> What's the status of this patch series? There don't seem to be many
> outstanding complaints but they haven't been pushed into master. At
> least the Xen changes have all been reviewed by Anthony (except for
>
On Wed, Jan 24, 2018 at 11:27:22AM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v3 4/7] kconfig/gcov: rename to coverage"):
> > So it can be used by both gcc and clang. Just add the Kconfig option
> > and modify the makefiles so the llvm coverage specific code can be
> > added in a f
Wei Liu writes ("Re: [PATCH v3 4/7] kconfig/gcov: rename to coverage"):
> On Wed, Jan 24, 2018 at 11:27:22AM +, Ian Jackson wrote:
> > This hunk seems erroneous ? Surely the name should be updated, but
> > the #ifdef should remain.
>
> No the ifdef needs to go.
>
> There is a new stub introd
On Wed, Jan 24, 2018 at 11:35:51AM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v3 4/7] kconfig/gcov: rename to coverage"):
> > On Wed, Jan 24, 2018 at 11:27:22AM +, Ian Jackson wrote:
> > > This hunk seems erroneous ? Surely the name should be updated, but
> > > the #ifdef should r
On 09/13/2017 05:21 PM, Dario Faggioli wrote:
> The patch introduces yet another runqueue arrangement option
> for Credit2. In fact, it allows the user to specify, explicitly
> and precisely, what pCPUs should belong to which runqueue.
>
> Signed-off-by: Dario Faggioli
> Signed-off-by: Praveen Ku
flight 118289 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118289/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
On 01/24/2018 11:44 AM, George Dunlap wrote:
> On 09/13/2017 05:21 PM, Dario Faggioli wrote:
>> The patch introduces yet another runqueue arrangement option
>> for Credit2. In fact, it allows the user to specify, explicitly
>> and precisely, what pCPUs should belong to which runqueue.
>>
>> Signed-
>>> On 24.01.18 at 12:00, wrote:
> --- a/xen/arch/x86/pv/shim.c
> +++ b/xen/arch/x86/pv/shim.c
> @@ -119,19 +119,23 @@ uint64_t pv_shim_mem(uint64_t avail)
> _PAGE_GUEST_KERNEL)
> #define COMPAT_L1_PROT (_PAGE_PRESENT|_PAGE_RW|_PAGE_ACCESSED)
>
> -static void __init replace_va
On 24/01/18 11:54, Roger Pau Monné wrote:
> On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote:
>> On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky
>> wrote:
>>> On 01/18/2018 05:33 AM, Wei Liu wrote:
On Thu, Jan 18, 2018 at 11:31:32AM +0100, Juergen Gross wrote:
> Wei,
>
>
On Thu, Oct 05, 2017 at 12:30:44PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> In current implementation the path of device XS entry is created with
> string from libxl__device_kind enum. But access to the device entry
> usually done with hardcoded path. This is source of potent
The functions in compat.c are thing wrappers around the main hypercalls,
massaging certain parameters. However, they second-guess the content of
pv_hypercall_table[], which is problematic for the shim case. Instead,
arrange for them to call via function pointer, which removes the need for
pv_get_
On 01/23/2018 04:05 PM, Ross Lagerwall wrote:
On 01/22/2018 12:29 PM, Jan Beulich wrote:
On 19.01.18 at 17:57, wrote:
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -511,6 +511,15 @@ static struct dmi_system_id __initdata
reboot_dmi_table[] = {
DMI_MATCH(DMI_PRO
flight 118287 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118287/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118277
test-armhf-armhf-libvirt 14 sav
On Tue, Nov 14, 2017 at 01:56:11PM +, Wei Liu wrote:
> On Tue, Nov 14, 2017 at 05:12:26PM +0530, Bhupinder Thakur wrote:
> > Hi,
> >
> > On 14 Nov 2017 3:35 pm, "Wei Liu" wrote:
> >
> > > On Mon, Nov 13, 2017 at 03:56:23PM +, Julien Grall wrote:
> > > > Hi Wei,
> > > >
> > > > Sorry I mi
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
---
tools/libvchan/Makefile | 2 +-
tools/libxc/Makefile| 2 +-
tools/libxl/Makefile| 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile
index ca9fc6354e..8d45fc2411 100644
--
Wei Liu writes ("[PATCH] tools: bump library version numbers to 4.11"):
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
The fix for XSA-242 depends on the same cpu never calling
_put_page_type() while holding a page_lock() for that page. By having
no locking discipline between pages, the current code also assumes
that we will never lock two pages on the same cpu.
Add a check to debug builds to verify that both of
On Wed, Jan 24, 2018 at 12:16:09PM +, Andrew Cooper wrote:
> The functions in compat.c are thing wrappers around the main hypercalls,
> massaging certain parameters. However, they second-guess the content of
> pv_hypercall_table[], which is problematic for the shim case. Instead,
> arrange fo
All,
I am pleased to announce the release of Xen 4.8.3. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8
(tag RELEASE-4.8.3) or from the XenProject download page
http://www.xenproject.org/downloads/xen-archives/xen-p
>>> On 19.01.18 at 17:57, wrote:
> When EFI booting the Dell PowerEdge R740, it consistently wanders into the
> weeds and gets an invalid opcode in the EFI ResetSystem call.
> Quirk this hardware to use the ACPI reboot method instead.
>
> Example stack trace:
>
> [ Xen-4.11-unstable x86_64
On 24/01/18 06:08, Dongli Zhang wrote:
> Hi Juergen,
>
> Would you please let me know if pvscsi is still supported by the most recent
> xen, as 'vscsi' is not supported in domU config file and
> scsi-attach/scsi-detach
> are not supported by xl command.
>
> Are scsi-attach/scsi-detach still on t
>>> On 24.01.18 at 13:16, wrote:
> The functions in compat.c are thing wrappers around the main hypercalls,
> massaging certain parameters. However, they second-guess the content of
> pv_hypercall_table[], which is problematic for the shim case. Instead,
> arrange for them to call via function p
On 24/01/18 12:48, George Dunlap wrote:
> The fix for XSA-242 depends on the same cpu never calling
> _put_page_type() while holding a page_lock() for that page. By having
> no locking discipline between pages, the current code also assumes
> that we will never lock two pages on the same cpu.
>
>
>>> On 24.01.18 at 13:48, wrote:
> The fix for XSA-242 depends on the same cpu never calling
> _put_page_type() while holding a page_lock() for that page. By having
> no locking discipline between pages, the current code also assumes
> that we will never lock two pages on the same cpu.
>
> Add a
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
---
xen/arch/x86/domctl.c | 2 ++
xen/arch/x86/hvm/hvm.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 2585d4e..1a15a34 100644
--- a/xen/arch/x86/domctl.c
+++
ret instructions are speculated directly to values recorded in the Return
Stack Buffer/Return Address Stack, as there is no uncertainty in well-formed
code. Guests can take advantage of this in two ways:
1) If they can find a path in Xen which executes more ret instructions than
call instr
Intel specifies IBRS/IBPB (combined, in a single bit) and STIBP as a separate
bit. AMD specifies IBPB alone in a 3rd bit.
AMD's IBPB is a subset of Intel's combined IBRS/IBPB. For performance
reasons, administrators might wish to express "IBPB only" even on Intel
hardware, so we allow the AMD bi
This patch is deliberately arranged to be easy to revert if/when alternatives
patching becomes NMI/#MC safe.
For safety, there must be a dispatch serialising instruction in (what is
logically) DO_SPEC_CTRL_ENTRY so that, in the case that Xen needs IBRS set in
context, an attacker can't speculate a
For performance reasons, HVM guests should have direct access to these MSRs
when possible.
Signed-off-by: Andrew Cooper
Reviewed-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
Reviewed-by: Kevin Tian
---
v7:
* Drop excess brackets
v9:
* Re-implement it light of Intels new spec. Drop R-by's.
Issuing an IBPB command flushes the Branch Target Buffer, so that any poison
left by one vcpu won't remain when beginning to execute the next.
The cost of IBPB is substantial, and skipped on transition to idle, as Xen's
idle code is robust already. All transitions into vcpu context are fully
seri
This series is availabe in git form from:
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/sp2-mitigations-v10
A copy of Intel's spec for IBRS/IBPB can be found here:
https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution
See the logic and comments in init_speculation_mitigations() for further
details.
There are two controls for RSB overwriting, because in principle there are
cases where it might be safe to forego rsb_native (Off the top of my head,
SMEP active, no 32bit PV guests at all, no use of vmevent/paging s
As per the spec currently available here:
https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
MSR_ARCH_CAPABILITIES will only come into existence on new hardware, but is
implemented as a straight #GP for now to avoid being leaky w
We need to be able to either set or clear IBRS in Xen context, as well as
restore appropriate guest values in guest context. See the documentation in
asm-x86/spec_ctrl_asm.h for details.
With the contemporary microcode, writes to %cr3 are slower when SPEC_CTRL.IBRS
is set. Therefore, the positio
With all infrastructure in place, it is now safe to let guests see and use
these features.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Acked-by: Wei Liu
---
v9:
* Split patch in half with the libxc hunk moving earlier, and rebasing over
the changed nature of STIBP
---
xen/include/pu
On contemporary hardware, setting IBRS/STIBP has a performance impact on
adjacent hyperthreads. It is therefore recommended to clear the setting
before becoming idle, to avoid an idle core preventing adjacent userspace
execution from running at full performance.
Care must be taken to ensure there
On Wed, 2018-01-24 at 13:12 +, Andrew Cooper wrote:
> + * Squash the domid and vcpu id together for comparason
*comparison
> + * efficiency. We could in principle stash and compare the
> struct
> + * vcpu pointer, but this risks a false alias if a domain
On 24/01/18 13:34, Woodhouse, David wrote:
> On Wed, 2018-01-24 at 13:12 +, Andrew Cooper wrote:
>> + * Squash the domid and vcpu id together for comparason
> *comparison
>
>> + * efficiency. We could in principle stash and compare the
>> struct
>> + * vcpu
On 01/24/2018 07:06 AM, Juergen Gross wrote:
> On 24/01/18 11:54, Roger Pau Monné wrote:
>> On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote:
>>> On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky
>>> wrote:
On 01/18/2018 05:33 AM, Wei Liu wrote:
> On Thu, Jan 18, 2018 at 11:31
On 01/24/2018 01:04 PM, Andrew Cooper wrote:
> On 24/01/18 12:48, George Dunlap wrote:
>> The fix for XSA-242 depends on the same cpu never calling
>> _put_page_type() while holding a page_lock() for that page. By having
>> no locking discipline between pages, the current code also assumes
>> that
The use of __LINE__ in printk()'s is problematic for livepatching, as it tends
to cause unnecessary binary differences.
Take this opportunity to provide some rather more useful information than just
file/line/func in the form of the full register/stack trace leading to the
problem (which I've need
Allow updating those two adjacent 32bit fields with one 64bit write.
This fixes qemu crash when booting Xen inside.
See discussion on Xen side of the thing here:
http://xen.markmail.org/message/6mrmemrnmhxvaxba
Signed-off-by: Marek Marczykowski-Górecki
---
hw/i386/intel_iommu.c | 8 ++--
1
On 24/01/18 15:10, Boris Ostrovsky wrote:
> On 01/24/2018 07:06 AM, Juergen Gross wrote:
>> On 24/01/18 11:54, Roger Pau Monné wrote:
>>> On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote:
On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky
wrote:
> On 01/18/2018 05:33 AM, W
On Wed, 2018-01-24 at 13:49 +, Andrew Cooper wrote:
> On 24/01/18 13:34, Woodhouse, David wrote:
> > I am loath to suggest *more* tweakables, but given the IBPB cost is
> > there any merit in having a mode which does it only if the *domain* is
> > different, regardless of vcpu_id?
>
> This woul
Architecturally there is only one GICv3 redistributor region.
Drop the symbol which suggested that was a delibarate choice for Xen
guests, instead hard code the "1" in the appropriate places, along with
a comment to explain the reasons.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3.c
The GICv3 devicetree binding describes two optional properties
(redistributor-stride and #redistributor-regions), which are meant to work
around implementations which deviate from the architecture. By the nature
of those they are only needed if the values are different from what the
architecture de
The last patch removed the usage of the hardware's redistributor-stride
value from our (Dom0) GICv3 emulation. This means we no longer need to
store this value in the VGIC data structure.
Remove that variable and every code snippet that handled that, instead
simply always use the architected value.
Instead of hard coding the architected redistributor stride into the
code, lets use a clear #define to the two values for GICv3 and GICv4 and
clarify the algorithm to determine the needed stride value.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3.c | 18 ++
x
The code to generate the DT node or MADT table for Dom0 reaches into the
domain's VGIC structure to learn the number of redistributor regions and
their base addresses.
Since those values are copied from the hardware, we can as well use
those hardware values directly when setting up the hardware dom
The ARM GICv3 DT property "#redistributor-regions" is optional and only
useful if it has any other values than the architected "1".
Keep our generated DT node clean by emitting this property only if we
actually need more than one region.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3.c |
When creating a GICv3 devicetree node, we currently insert the
redistributor-stride and #redistributor-regions properties, with fixed
values which are actually the architected ones. But those properties are
optional and only needed to cover for broken platforms, where the values
differ from the arc
The redistributor-stride property in a GICv3 DT node is only there to
cover broken platforms where this value deviates from the architected one.
Since we emulate the GICv3 distributor even for Dom0, we don't need to
copy the broken behaviour. All the special handling for Dom0s using
GICv3 is just f
On 01/24/2018 09:25 AM, Juergen Gross wrote:
> On 24/01/18 15:10, Boris Ostrovsky wrote:
>>
>> I suspect we can do as little as removing "#ifdef CONFIG_KEXEC" around
>> acpi_rsdp in drivers/acpi/osl.c and then assigning it the value in
>> pvh_start_info.rsdp_paddr. (I haven't tried it)
> That was t
flight 118305 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118305/
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 Wed, Jan 24, 2018 at 09:42:57AM -0500, Boris Ostrovsky wrote:
> On 01/24/2018 09:25 AM, Juergen Gross wrote:
> > On 24/01/18 15:10, Boris Ostrovsky wrote:
> >>
> >> I suspect we can do as little as removing "#ifdef CONFIG_KEXEC" around
> >> acpi_rsdp in drivers/acpi/osl.c and then assigning it t
The fix for XSA-242 depends on the same cpu never calling
_put_page_type() while holding a page_lock() for that page; doing so
may cause a deadlock under the right conditions.
Furthermore, even before that, there was never any discipline for the
order in which page locks are grabbed; if there are
On Wed, Jan 24, 2018 at 2:10 PM, Boris Ostrovsky
wrote:
> On 01/24/2018 07:06 AM, Juergen Gross wrote:
>> On 24/01/18 11:54, Roger Pau Monné wrote:
>>> On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote:
On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky
wrote:
> On 01/18/2
On 01/24/2018 05:01 AM, Roger Pau Monne wrote:
llvm coverage support seems to disable some of the optimizations
needed in order to compile xsm, and the end result is that references
to __xsm_action_mismatch_detected are left in the object files.
Since coverage support cannot be used in productio
On 24/01/18 16:07, George Dunlap wrote:
> On Wed, Jan 24, 2018 at 2:10 PM, Boris Ostrovsky
> wrote:
>> On 01/24/2018 07:06 AM, Juergen Gross wrote:
>>> On 24/01/18 11:54, Roger Pau Monné wrote:
On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote:
> On Wed, Jan 24, 2018 at 2:41 A
On Wed, Jan 24, 2018 at 3:20 PM, Juergen Gross wrote:
> On 24/01/18 16:07, George Dunlap wrote:
>> On Wed, Jan 24, 2018 at 2:10 PM, Boris Ostrovsky
>> wrote:
>>> On 01/24/2018 07:06 AM, Juergen Gross wrote:
On 24/01/18 11:54, Roger Pau Monné wrote:
> On Wed, Jan 24, 2018 at 10:42:39AM +0
>>> On 24.01.18 at 15:11, wrote:
> The use of __LINE__ in printk()'s is problematic for livepatching, as it tends
> to cause unnecessary binary differences.
>
> Take this opportunity to provide some rather more useful information than just
> file/line/func in the form of the full register/stack t
>>> On 24.01.18 at 16:02, wrote:
> The fix for XSA-242 depends on the same cpu never calling
> _put_page_type() while holding a page_lock() for that page; doing so
> may cause a deadlock under the right conditions.
>
> Furthermore, even before that, there was never any discipline for the
> order
On 24/01/18 15:41, Jan Beulich wrote:
On 24.01.18 at 15:11, wrote:
>> The use of __LINE__ in printk()'s is problematic for livepatching, as it
>> tends
>> to cause unnecessary binary differences.
>>
>> Take this opportunity to provide some rather more useful information than
>> just
>> file
On 24/01/18 15:43, Jan Beulich wrote:
On 24.01.18 at 16:02, wrote:
>> The fix for XSA-242 depends on the same cpu never calling
>> _put_page_type() while holding a page_lock() for that page; doing so
>> may cause a deadlock under the right conditions.
>>
>> Furthermore, even before that, ther
1 - 100 of 186 matches
Mail list logo
