[Xen-devel] [GIT PULL] xen: fix for 4.15-rc7

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.15-rc7-tag xen: fix for 4.15-rc7 It contains one minor fix adjusting the kmalloc flags in the new pvcalls driver added in rc1. Thanks. Juergen drivers/xen/pvcalls-front.c | 2 +-

[Xen-devel] [PATCH] xen-netfront: enable device after manual module load

When loading the module after unloading it, the network interface would not be enabled and thus wouldn't have a backend counterpart and unable to be used by the guest. The guest would face errors like: [root@guest ~]# ethtool -i eth0 Cannot get driver information: No such device [root@gues

[Xen-devel] Ping: [PATCH RFC v2] x86/domctl: Don't pause the whole domain if only getting vcpu state

Any thoughts appreciated. On Vi, 2017-10-06 at 13:02 +0300, Alexandru Isaila wrote: > This patch adds the hvm_save_one_cpu_ctxt() function. > It optimizes by only pausing the vcpu on all HVMSR_PER_VCPU save > callbacks where only data for one VCPU is required. > > Signed-off-by: Alexandru Isaila

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

> -Original Message- > From: Kevin Stange [mailto:ke...@steadfast.net] > Sent: 04 January 2018 21:17 > To: Paul Durrant > Cc: George Dunlap ; xen- > de...@lists.xenproject.org; Anthony Perard > Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to > Upstream > > On 01/04

[Xen-devel] Xen 4.11 Development Update

This email only tracks big items for xen.git tree. Please reply for items you would like to see in 4.11 so that people have an idea what is going on and prioritise accordingly. You're welcome to provide description and use cases of the feature you're working on. = Timeline = We now adopt a fixed

Re: [Xen-devel] [PATCH RFC 01/44] passthrough/vtd: Don't DMA to the stack in queue_invalidate_wait()

>>> On 04.01.18 at 21:21, wrote: > DMA-ing to the stack is generally considered bad practice. In this case, if a > timeout occurs because of a sluggish device which is processing the request, > the completion notification will corrupt the stack of a subsequent deeper call > tree. > > Place the p

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On 05/01/2018 07:48, Juergen Gross wrote: > On 04/01/18 21:21, Andrew Cooper wrote: >> This work was developed as an SP3 mitigation, but shelved when it became >> clear >> that it wasn't viable to get done in the timeframe. >> >> To protect against SP3 attacks, most mappings needs to be flushed wh

Re: [Xen-devel] Xen 4.11 Development Update

>>> On 05.01.18 at 10:16, wrote: > === x86 === > > * Enable Memory Bandwidth Allocation in Xen (v10) > - XEN-48 > - Yi Sun > > * guest resource mapping (v17) > - Paul Durrant > > * vNVDIMM support for HVM guest (RFC v4) > - XEN-45 > - Haozhong Zhang > > * SMMUv3 driver (RFC

Re: [Xen-devel] [PATCH RFC 01/44] passthrough/vtd: Don't DMA to the stack in queue_invalidate_wait()

On 05/01/2018 09:21, Jan Beulich wrote: On 04.01.18 at 21:21, wrote: >> DMA-ing to the stack is generally considered bad practice. In this case, if >> a >> timeout occurs because of a sluggish device which is processing the request, >> the completion notification will corrupt the stack of a

Re: [Xen-devel] Dynamic Disassembling domU Instructions

>>> On 05.01.18 at 04:17, wrote: > I am trying to modify Xen 4.8 to have it print out the opcode as well as > some registers of an HVM domU as it runs. I tried to modify > xen/arch/x86/hvm/emulate.c 's hvmemul_insn_fetch to output the content in > hvmemul_ctxt->insn_buf with printk. In hvmemul_ins

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On 05/01/18 10:26, Andrew Cooper wrote: > On 05/01/2018 07:48, Juergen Gross wrote: >> On 04/01/18 21:21, Andrew Cooper wrote: >>> This work was developed as an SP3 mitigation, but shelved when it became >>> clear >>> that it wasn't viable to get done in the timeframe. >>> >>> To protect against S

Re: [Xen-devel] Xen 4.11 Development Update

Hello Juergen, On 5 January 2018 at 14:46, Juergen Gross wrote: > This email only tracks big items for xen.git tree. Please reply for items you > would like to see in 4.11 so that people have an idea what is going on and > prioritise accordingly. > > You're welcome to provide description and use

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On 05/01/2018 09:39, Juergen Gross wrote: > On 05/01/18 10:26, Andrew Cooper wrote: >> On 05/01/2018 07:48, Juergen Gross wrote: >>> On 04/01/18 21:21, Andrew Cooper wrote: This work was developed as an SP3 mitigation, but shelved when it became clear that it wasn't viable to get do

Re: [Xen-devel] Xen 4.11 Development Update

On 05/01/18 10:32, Jan Beulich wrote: On 05.01.18 at 10:16, wrote: >> === x86 === >> >> * Enable Memory Bandwidth Allocation in Xen (v10) >> - XEN-48 >> - Yi Sun >> >> * guest resource mapping (v17) >> - Paul Durrant >> >> * vNVDIMM support for HVM guest (RFC v4) >> - XEN-45 >

Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Paul Durrant > Sent: 03 January 2018 16:48 > To: 'Jan Beulich' > Cc: StefanoStabellini ; Wei Liu > ; Andrew Cooper ; Tim > (Xen.org) ; George Dunlap ; > JulienGrall ; Ian Jackson ; > xen-d

Re: [Xen-devel] Xen 4.11 Development Update

>>> On 05.01.18 at 10:57, wrote: > On 05/01/18 10:32, Jan Beulich wrote: >> Another x86 item are the emulator additions to support post-AVX >> insns and some other, earlier ones we don't have support for >> yet. The main parts of that series have now been pending review >> for over half a year, I

Re: [Xen-devel] Xen 4.11 Development Update

> -Original Message- > From: Juergen Gross [mailto:jgr...@suse.com] > Sent: 05 January 2018 09:17 > To: xen-devel@lists.xenproject.org > Cc: jgr...@suse.com > Subject: Xen 4.11 Development Update > > This email only tracks big items for xen.git tree. Please reply for items you > would like

Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

>>> On 05.01.18 at 11:16, wrote: >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf >> Of Paul Durrant >> Sent: 03 January 2018 16:48 >> Ok, thanks. If change back to having the pages owned by the tools domain >> then I guess this will all be avoided anyway. > > I've run

Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 05 January 2018 10:29 > To: Paul Durrant > Cc: JulienGrall ; Andrew Cooper > ; George Dunlap > ; Ian Jackson ; Wei Liu > ; StefanoStabellini ; xen- > de...@lists.xenproject.org; Tim (Xen.org) > Subject: RE: [Xen-d

Re: [Xen-devel] [PATCH RFC v1 10/74] x86/time: Print a more helpful error when a platform timer can't be found

>>> On 04.01.18 at 14:05, wrote: > From: Andrew Cooper > > Signed-off-by: Andrew Cooper > Reviewed-by: Wei Liu Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-deve

Re: [Xen-devel] [PATCH RFC v1 11/74] x86/link: Introduce and use SECTION_ALIGN

>>> On 04.01.18 at 14:05, wrote: > From: Andrew Cooper > > ... to reduce the quantity of #ifdef EFI. > > Signed-off-by: Andrew Cooper > Reviewed-by: Wei Liu Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https:/

Re: [Xen-devel] [PATCH RFC v1 12/74] xen/acpi: mark the PM timer FADT field as optional

>>> On 04.01.18 at 14:05, wrote: > From: Roger Pau Monne > > According to the ACPI 6.1 specification this field is optional, so > mark it as such. > > Signed-off-by: Roger Pau Monné This would probably better be a direct port of Linux commit 1d82980c99 (obviously just the tbfadt.c parts of it

Re: [Xen-devel] [PATCH RFC v1 13/74] xen/domctl: Return arch_config via getdomaininfo

>>> On 04.01.18 at 14:05, wrote: > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -116,6 +116,7 @@ struct xen_domctl_getdomaininfo { > uint32_t ssidref; > xen_domain_handle_t handle; > uint32_t cpupool; > +struct xen_arch_domainconfig arch_config; >

Re: [Xen-devel] [PATCH RFC v1 16/74] x86/fixmap: Modify fix_to_virt() to return a void pointer

>>> On 04.01.18 at 14:05, wrote: > --- a/xen/drivers/acpi/apei/apei-io.c > +++ b/xen/drivers/acpi/apei/apei-io.c > @@ -92,7 +92,7 @@ static void __iomem *__init apei_range_map(paddr_t paddr, > unsigned long size) > apei_range_nr++; > } > > - return (void __iomem *)fix_to

Re: [Xen-devel] [PATCH RFC v1 17/74] ---- x86/Kconfig: Options for Xen and PVH support

>>> On 04.01.18 at 14:05, wrote: Please drop the stray from the subject. > From: Andrew Cooper > > Signed-off-by: Andrew Cooper No description (rationale) at all? But perhaps that's to be attributed to the RFC nature of the series. > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kcon

Re: [Xen-devel] [PATCH RFC v1 18/74] x86/link: Relocate program headers

>>> On 04.01.18 at 14:05, wrote: > From: Andrew Cooper > > When the xen binary is loaded by libelf (in the future) we rely on the > elf loader to load the binary accordingly. It would really help if it was said here what effect this has on the program headers - I can only guess that it'll make

[Xen-devel] [distros-debian-jessie test] 73932: trouble: blocked/broken

flight 73932 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/73932/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-i38

Re: [Xen-devel] [PATCH RFC v1 19/74] x86: introduce ELFNOTE macro

>>> On 04.01.18 at 14:05, wrote: > It is needed later for introducing PVH entry point. Perhaps worth moving the addition there, rather than introducing dead code here? > --- a/xen/include/asm-x86/asm_defns.h > +++ b/xen/include/asm-x86/asm_defns.h > @@ -409,4 +409,16 @@ static always_inline void

[Xen-devel] Xen Project Spectre/Meltdown FAQ

Hi all, this is a repost of https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ for xen-users/xen-devel. If you have questions, please reply to this thread and we will try and improve the FAQ based on questions. Regards Lars Google’s Project Zero announced several informati

Re: [Xen-devel] [PATCH RFC v1 20/74] x86: produce a binary that can be booted as PVH

>>> On 04.01.18 at 14:05, wrote: > Signed-off-by: Wei Liu > Signed-off-by: Andrew Cooper Again I assume a description is still being intended to be written > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -75,6 +75,8 @@ efi-y := $(shell if [ ! -r > $(BASEDIR)/include/xen/compi

[Xen-devel] [xen-unstable test] 117617: regressions - trouble: broken/fail/pass

flight 117617 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/117617/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm broken test-amd64-amd64-xl-qcow2

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

On 05/01/18 12:35, Lars Kurth wrote: > Hi all, this is a repost of > https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ for > xen-users/xen-devel. If you have questions, please reply to this thread and > we will try and improve the FAQ based on questions. > Regards > Lars >

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

On 01/05/2018 11:35 AM, Lars Kurth wrote: > Hi all, this is a repost of > https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ for > xen-users/xen-devel. If you have questions, please reply to this thread and > we will try and improve the FAQ based on questions. I also starte

Re: [Xen-devel] [PATCH RFC v1 21/74] x86/entry: Early PVH boot code

>>> On 04.01.18 at 14:05, wrote: > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -380,7 +380,39 @@ cs32_switch: > ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY, .long sym_offs(__pvh_start)) > > __pvh_start: > -ud2a > +cld > +cli > + > +/* > +

Re: [Xen-devel] [PATCH RFC v1 23/74] x86/entry: Probe for Xen early during boot

>>> On 04.01.18 at 14:05, wrote: > --- /dev/null > +++ b/xen/arch/x86/guest/xen.c > @@ -0,0 +1,75 @@ > +/** > + * arch/x86/guest/xen.c > + * > + * Support for detecting and running under Xen. > + * > + * This program is fr

Re: [Xen-devel] [PATCH v1] x86/mm: Supresses vm_events caused by page-walks

On 10/30/2017 07:38 PM, Tamas K Lengyel wrote: > On Mon, Oct 30, 2017 at 11:19 AM, Razvan Cojocaru > wrote: >> On 10/30/2017 07:07 PM, Tamas K Lengyel wrote: >>> On Mon, Oct 30, 2017 at 11:01 AM, Razvan Cojocaru >>> wrote: On 10/30/2017 06:39 PM, Tamas K Lengyel wrote: > On Mon, Oct 30,

Re: [Xen-devel] [PATCH RFC v1 24/74] x86/guest: Hypercall support

>>> On 04.01.18 at 14:05, wrote: > --- /dev/null > +++ b/xen/arch/x86/guest/hypercall_page.S > @@ -0,0 +1,79 @@ > +#include > +#include > +#include > + > +.section ".text.page_aligned", "ax", @progbits > +.p2align PAGE_SHIFT > + > +GLOBAL(hypercall_page) > + /* Poisoned

Re: [Xen-devel] [PATCH RFC v1 25/74] x86/shutdown: Support for using SCHEDOP_{shutdown, reboot}

>>> On 04.01.18 at 14:05, wrote: > From: Andrew Cooper > > Signed-off-by: Andrew Cooper > Signed-off-by: Wei Liu Reviewed-by: Jan Beulich with two remarks: > --- a/xen/include/asm-x86/guest/hypercall.h > +++ b/xen/include/asm-x86/guest/hypercall.h > @@ -19,6 +19,11 @@ > #ifndef __X86_XEN_H

Re: [Xen-devel] [PATCH RFC v1 26/74] x86/pvh: Retrieve memory map from Xen

>>> On 04.01.18 at 14:05, wrote: > Signed-off-by: Wei Liu > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC v1 27/74] xen/console: Introduce console=xen

>>> On 04.01.18 at 14:05, wrote: > From: Andrew Cooper > > This specifies whether to use Xen specific console output. There are > two variants: one is the hypervisor console, the other is the magic > debug port 0xe9. With just x86 in mind this is all fine, but for ARM (and for other reasons eve

Re: [Xen-devel] [PATCH RFC v1 24/74] x86/guest: Hypercall support

On 05/01/18 13:53, Jan Beulich wrote: On 04.01.18 at 14:05, wrote: >> --- /dev/null >> +++ b/xen/arch/x86/guest/hypercall_page.S >> @@ -0,0 +1,79 @@ >> +#include >> +#include >> +#include >> + >> +.section ".text.page_aligned", "ax", @progbits >> +.p2align PAGE_SHIFT >> + >

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On Fri, Jan 5, 2018 at 9:39 AM, Juergen Gross wrote: > On 05/01/18 10:26, Andrew Cooper wrote: >> On 05/01/2018 07:48, Juergen Gross wrote: >>> On 04/01/18 21:21, Andrew Cooper wrote: This work was developed as an SP3 mitigation, but shelved when it became clear that it wasn't viab

Re: [Xen-devel] [PATCH RFC v1 28/74] x86: initialise shared_info page

>>> On 04.01.18 at 14:05, wrote: > --- a/xen/arch/x86/guest/xen.c > +++ b/xen/arch/x86/guest/xen.c > @@ -72,6 +72,30 @@ void __init probe_hypervisor(void) > xen_guest = true; > } > > +static void map_shared_info(struct e820map *e820) > +{ > +paddr_t frame = 0xff00; /* TODO: Hardcod

Re: [Xen-devel] [PATCH v2 5/6] xen: Add only xen-sysdev to dynamic sysbus device list

On Sat, Nov 25, 2017 at 01:16:09PM -0200, Eduardo Habkost wrote: > There's no need to make the machine allow every possible sysbus > device. We can now just add xen-sysdev to the allowed list. > > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc: xen-devel@lists.xenproject.org > Cc: Juergen Gro

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On 05/01/18 15:11, George Dunlap wrote: > On Fri, Jan 5, 2018 at 9:39 AM, Juergen Gross wrote: >> On 05/01/18 10:26, Andrew Cooper wrote: >>> On 05/01/2018 07:48, Juergen Gross wrote: On 04/01/18 21:21, Andrew Cooper wrote: > This work was developed as an SP3 mitigation, but shelved when

Re: [Xen-devel] [PATCH RFC v1 29/74] x86: xen pv clock time source

>>> On 04.01.18 at 14:05, wrote: > It is a variant of TSC clock source. > > Signed-off-by: Wei Liu > Signed-off-by: Andrew Cooper > Signed-off-by: Roger Pau Monné Mostly fine, with the TODO addressed, u64 etc replaced by uint64_t etc, ... > +static always_inline > +u64 __read_cycle(const str

Re: [Xen-devel] [PATCH RFC v1 28/74] x86: initialise shared_info page

On 05/01/18 14:11, Jan Beulich wrote: On 04.01.18 at 14:05, wrote: >> --- a/xen/arch/x86/guest/xen.c >> +++ b/xen/arch/x86/guest/xen.c >> @@ -72,6 +72,30 @@ void __init probe_hypervisor(void) >> xen_guest = true; >> } >> >> +static void map_shared_info(struct e820map *e820) >> +{ >> +

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

>>> On 05.01.18 at 15:11, wrote: > Here's a question: What if we didn't try to prevent the guest from > reading hypervisor memory at all, but instead just tried to make sure > that there was nothing of interest there? > > If sensitive information pertaining to a given vcpu were only maped on > t

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

>>> On 05.01.18 at 15:21, wrote: > We already have map_domain_page(), as a result of 32-bit mode and >>5TiB mode, so getting the domain pages out of the HV should be pretty > easy. E.g. by doing away with the directmap altogether. Jan ___ Xen-devel m

Re: [Xen-devel] [PATCH RFC v1 28/74] x86: initialise shared_info page

On Fri, Jan 05, 2018 at 02:20:16PM +, Andrew Cooper wrote: > On 05/01/18 14:11, Jan Beulich wrote: > On 04.01.18 at 14:05, wrote: > >> --- a/xen/arch/x86/guest/xen.c > >> +++ b/xen/arch/x86/guest/xen.c > >> @@ -72,6 +72,30 @@ void __init probe_hypervisor(void) > >> xen_guest = true;

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On Fri, Jan 5, 2018 at 2:17 PM, Juergen Gross wrote: > On 05/01/18 15:11, George Dunlap wrote: >> On Fri, Jan 5, 2018 at 9:39 AM, Juergen Gross wrote: >>> On 05/01/18 10:26, Andrew Cooper wrote: On 05/01/2018 07:48, Juergen Gross wrote: > On 04/01/18 21:21, Andrew Cooper wrote: >> Th

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On 05/01/18 14:27, Jan Beulich wrote: On 05.01.18 at 15:11, wrote: >> Here's a question: What if we didn't try to prevent the guest from >> reading hypervisor memory at all, but instead just tried to make sure >> that there was nothing of interest there? >> >> If sensitive information pertai

Re: [Xen-devel] [PATCH RFC v1 30/74] x86: APIC timer calibration when running as a guest

>>> On 04.01.18 at 14:05, wrote: > The timer calibration depends on the number of ticks. Introduce a > variant to wait for a tick when running as a guest. The change itself is fine, i.e. Reviewed-by: Jan Beulich but the description (to me, but it may be just me) doesn't really match it. How abou

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

(apologies for the formatting) Hi Lars, Thank you for putting together an FAQ. Few comments below around Arm. On 5 Jan 2018 13:37, "Lars Kurth" wrote: Hi all, this is a repost of https://blog.xenproject.org/ 2018/01/04/xen-project-spectremeltdown-faq/ for xen-users/xen-devel. If you have que

Re: [Xen-devel] [PATCH RFC v1 28/74] x86: initialise shared_info page

On 05/01/18 14:28, Roger Pau Monné wrote: > On Fri, Jan 05, 2018 at 02:20:16PM +, Andrew Cooper wrote: >> On 05/01/18 14:11, Jan Beulich wrote: >> On 04.01.18 at 14:05, wrote: --- a/xen/arch/x86/guest/xen.c +++ b/xen/arch/x86/guest/xen.c @@ -72,6 +72,30 @@ void __init probe_

Re: [Xen-devel] [PATCH RFC v1 31/74] x86: read wallclock from Xen running in pvh mode

>>> On 04.01.18 at 14:05, wrote: > Signed-off-by: Wei Liu Reviewed-by: Jan Beulich with a suggestion on code structure: > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -969,6 +969,36 @@ static unsigned long get_cmos_time(void) > return mktime(rtc.year, rtc.mon, rtc.day, rtc.h

Re: [Xen-devel] [PATCH RFC v1 32/74] x86: don't swallow the first command line item in pvh mode

>>> On 04.01.18 at 14:05, wrote: > @@ -632,11 +633,10 @@ static char * __init cmdline_cook(char *p, const char > *loader_name) > while ( *p == ' ' ) > p++; > > -/* GRUB2 does not include image name as first item on command line. */ > -if ( loader_is_grub2(loader_name) ) >

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

Julien, > On 5 Jan 2018, at 14:40, Julien Grall wrote: > > (apologies for the formatting) > > Hi Lars, > > Thank you for putting together an FAQ. > > Few comments below around Arm. > > Systems running Xen, like all operating systems and hypervisors, are > potentially affected by Spectre (re

Re: [Xen-devel] [PATCH RFC v1 33/74] x86/guest: enable event channels upcalls

>>> On 04.01.18 at 14:05, wrote: > @@ -30,6 +31,7 @@ > bool xen_guest; > > static uint32_t xen_cpuid_base; > +static uint8_t evtchn_upcall_vector; There being a single global vector, why do you use HVMOP_set_evtchn_upcall_vector instead of setting HVM_PARAM_CALLBACK_IRQ? Aiui this would also

Re: [Xen-devel] [PATCH RFC v1 33/74] x86/guest: enable event channels upcalls

On 05/01/18 15:07, Jan Beulich wrote: On 04.01.18 at 14:05, wrote: >> @@ -30,6 +31,7 @@ >> bool xen_guest; >> >> static uint32_t xen_cpuid_base; >> +static uint8_t evtchn_upcall_vector; > There being a single global vector, why do you use > HVMOP_set_evtchn_upcall_vector instead of settin

Re: [Xen-devel] [PATCH RFC v1 34/74] x86/guest: add PV console code

>>> On 04.01.18 at 14:05, wrote: > --- /dev/null > +++ b/xen/drivers/char/xen_pv_console.c > @@ -0,0 +1,198 @@ > +/** > + * drivers/char/xen_pv_console.c > + * > + * A frontend driver for Xen's PV console. > + * Can be use

Re: [Xen-devel] [PATCH RFC v1 36/74] --- x86/shim: Kconfig and command line options

>>> On 04.01.18 at 14:05, wrote: > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -133,6 +133,28 @@ config PVH_GUEST > ---help--- > Support booting using the PVH ABI. > > + If unsure, say N. > + > +config PV_SHIM > + def_bool n > + prompt "PV Shim" > +

Re: [Xen-devel] [PATCH 2/2] x86/svm: Add checks for nested HW features

On Fri, Dec 22, 2017 at 03:15:48PM +, Andrew Cooper wrote: > Unfortunately, nestedhvm_enabled() is guaranteed to be false at the > point that construct_vmcb() is called (due the order in which > information appears while constructing the VM), which means we will > never enable these optimisatio

[Xen-devel] [linux-linus test] 117623: regressions - trouble: broken/fail/pass

flight 117623 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/117623/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm broken test-amd64-i386-qemuu-rhel6hvm-

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

On 01/05/2018 12:35 PM, Lars Kurth wrote: > Hi all, this is a repost of > https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ > for xen-users/xen-devel. If you have questions, please reply to this > thread and we will try and improve the FAQ based on questions. > Regards Lars

[Xen-devel] [PATCH] x86/efi: fix build with linkers that support both coff-x86-64 and pe-x86-64

When using a linker that supports both formats the following error will be triggered: efi/buildid.o: file not recognized: File format is ambiguous efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 Solve this by specifying the buildid.o format to pe-x86-64. Signed-off-by: Roger Pau Monné --

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

On 01/05/2018 03:03 AM, Paul Durrant wrote: >> -Original Message- >> From: Kevin Stange [mailto:ke...@steadfast.net] >> Sent: 04 January 2018 21:17 >> To: Paul Durrant >> Cc: George Dunlap ; xen- >> de...@lists.xenproject.org; Anthony Perard >> Subject: Re: [Xen-devel] PCI Device Subtree

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

On 01/04/2018 03:16 PM, Kevin Stange wrote: > On 01/04/2018 06:52 AM, Anthony PERARD wrote: >> On Wed, Jan 03, 2018 at 05:10:54PM -0600, Kevin Stange wrote: >>> On 01/03/2018 11:57 AM, Anthony PERARD wrote: On Wed, Dec 20, 2017 at 11:40:03AM -0600, Kevin Stange wrote: > Hi, > > I'v

Re: [Xen-devel] Xen Security Advisory 254 - Information leak via side effects of speculative execution

I'm just adding some comments below on some updates that might be helpful to add to help clarify things for interested parties. These comments are driven purely based on the questions that I've had to field from others. - Since this advisory talks about 3 CVEs and then breaks the issue into 3 item

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

> On 5 Jan 2018, at 15:55, Hans van Kranenburg wrote: > > On 01/05/2018 12:35 PM, Lars Kurth wrote: >> Hi all, this is a repost of >> https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ >> >> for xen-u

Re: [Xen-devel] [PATCH RFC v1 36/74] --- x86/shim: Kconfig and command line options

On 05/01/18 15:26, Jan Beulich wrote: On 04.01.18 at 14:05, wrote: >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -133,6 +133,28 @@ config PVH_GUEST >> ---help--- >>Support booting using the PVH ABI. >> >> + If unsure, say N. >> + >> +config PV_SHIM >> +

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

> On Jan 5, 2018, at 06:35, Lars Kurth wrote: > > Hi all, this is a repost of > https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ for > xen-users/xen-devel. If you have questions, please reply to this thread and > we will try and improve the FAQ based on questions. Very

[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 3 Information leak via side effects of speculative execution UPDATES IN VERSION 3 Add information abou

[Xen-devel] [xen-4.8-testing test] 117628: trouble: broken/fail/pass

flight 117628 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117628/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-5 broken test-amd64-amd64-

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

On 05/01/18 18:16, Rich Persaud wrote: >> On Jan 5, 2018, at 06:35, Lars Kurth > > wrote: >> SP2 can be mitigated in two ways, both of which essentially prevent >> speculative execution of indirect branches. The first is to flush the >> branch prediction logic on en

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

On 01/05/2018 11:10 AM, Kevin Stange wrote: > On 01/04/2018 03:16 PM, Kevin Stange wrote: >> On 01/04/2018 06:52 AM, Anthony PERARD wrote: >>> On Wed, Jan 03, 2018 at 05:10:54PM -0600, Kevin Stange wrote: On 01/03/2018 11:57 AM, Anthony PERARD wrote: > On Wed, Dec 20, 2017 at 11:40:03AM -0

[Xen-devel] [libvirt test] 117631: regressions - trouble: broken/fail/pass

flight 117631 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/117631/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair broken test-amd64-amd64-libvirt-pair 4 host-install/

[Xen-devel] [xen-unstable-smoke test] 117663: tolerable all pass - PUSHED

flight 117663 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117663/ 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

Re: [Xen-devel] Dynamic Disassembling domU Instructions

Hi Jan, Thank you for the insight. That explains a lot of the repeated cached instruction fetching. This might belong to another thread, I was exploring xentrace, ran it with "sudo xentrace output", but it returns the message of "ERROR: Failed to map cpu buffer! (13 = Permission denied)", even run

[Xen-devel] [qemu-mainline test] 117633: regressions - trouble: broken/fail/pass

flight 117633 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/117633/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-xsm broken test-amd64-amd64-libvirt-vhd

Re: [Xen-devel] [PATCH] x86/efi: fix build with linkers that support both coff-x86-64 and pe-x86-64

On 1/5/18 10:43 AM, Roger Pau Monne wrote: > When using a linker that supports both formats the following error > will be triggered: > > efi/buildid.o: file not recognized: File format is ambiguous > efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 > > Solve this by specifying the buildid.o

[Xen-devel] [linux-4.9 test] 117637: tolerable FAIL - PUSHED

flight 117637 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/117637/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 117255 test-amd64-i386-xl-qemut-win7-amd64 17

Re: [Xen-devel] [PATCH 1/3] xen: remove tests for pvh mode in pure pv paths

Juergen Gross: > Remove the last tests for XENFEAT_auto_translated_physmap in pure > PV-domain specific paths. PVH V1 is gone and the feature will always > be "false" in PV guests. [...] > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c > index 276da636dd39..6083ba462f35 100644 > --- a/arch/x8