Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 15:55, Borislav Petkov wrote: > On Mon, Feb 08, 2016 at 10:39:43AM -0500, Boris Ostrovsky wrote: >> It does. Very much IIRC, the problem was not caused by an access to MSR but >> rather some sort of address not being available somewhere. > See below. > >>> - microcode application on

Re: [Xen-devel] [PATCH v2 2/2] xen/scsiback: avoid warnings when adding multiple LUNs to a domain

On 08/02/16 17:46, David Vrabel wrote: > On 08/02/16 14:30, Juergen Gross wrote: >> When adding more than one LUN to a frontend a warning for a failed >> assignment is issued in dom0 for each already existing LUN. Avoid this >> warning by checking for a LUN already existing when existence is >>

Re: [Xen-devel] [PATCH 1/2] xenoprof: fix up ability to disable it

On 08/02/16 16:04, Doug Goldstein wrote: > diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c > index 990e6f3..c7b5bd5 100644 > --- a/xen/arch/x86/cpu/vpmu_amd.c > +++ b/xen/arch/x86/cpu/vpmu_amd.c > @@ -22,6 +22,7 @@ > */ > > #include > +#include > #include >

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 02/08/2016 11:26 AM, Andrew Cooper wrote: On 08/02/16 16:12, Boris Ostrovsky wrote: On 02/08/2016 11:05 AM, Andrew Cooper wrote: For compatibility with other virtualisation specs, Xen's cpuid leaves shift depending on configuration. Spec at

Re: [Xen-devel] [PATCH v2 2/2] xen/scsiback: avoid warnings when adding multiple LUNs to a domain

On 08/02/16 14:30, Juergen Gross wrote: > When adding more than one LUN to a frontend a warning for a failed > assignment is issued in dom0 for each already existing LUN. Avoid this > warning by checking for a LUN already existing when existence is > allowed (scsiback_do_add_lun() called with try

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 02/08/2016 11:35 AM, Borislav Petkov wrote: On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote: I think we are OK for PV because this code will be executed after pvops are set and so we will be calling xen_cpuid(). Not for the early loader - it is too early for pvops then. So

Re: [Xen-devel] [PATCH v2 2/2] xen/scsiback: avoid warnings when adding multiple LUNs to a domain

On 08/02/16 16:50, Juergen Gross wrote: > On 08/02/16 17:46, David Vrabel wrote: >> On 08/02/16 14:30, Juergen Gross wrote: >>> When adding more than one LUN to a frontend a warning for a failed >>> assignment is issued in dom0 for each already existing LUN. Avoid this >>> warning by checking for

[Xen-devel] [PATCH 1/7] arm: move arch/arm/hvm.c to arch/arm/hvm/hvm.c

X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry, also move arch/arm/hvm.c to arch/arm/hvm/hvm.c. Signed-off-by: Corneliu ZUZU --- xen/arch/arm/Makefile | 2 +- xen/arch/arm/hvm.c| 67 ---

[Xen-devel] [PATCH 3/7] xen/vm-events: Move monitor_domctl to common-side.

1. Kconfig: * Added Kconfigs for common monitor vm-events: # see files: common/Kconfig, x86/Kconfig HAS_VM_EVENT_WRITE_CTRLREG HAS_VM_EVENT_SINGLESTEP HAS_VM_EVENT_SOFTWARE_BREAKPOINT HAS_VM_EVENT_GUEST_REQUEST 2. Moved monitor_domctl from arch-side to common-side 2.1. Moved

[Xen-devel] [PATCH 5/7] xen/vm-events: Move hvm_event_* functions to common-side.

1. Moved hvm_event_traps, hvm_event_cr, hvm_event_guest_request, hvm_event_software_breakpoint from arch-side to common-side 1.1. Moved arch/x86/hvm/event.c to common/hvm/event.c # see files: arch/x86/hvm/Makefile, xen/common/hvm/Makefile,

[Xen-devel] [PATCH 7/7] arch.monitor: move bits to common (arch_domain to domain)

This patch moves bitfield members for single-step, software-breakpoint and guest-request monitor vm-events from the arch-side (struct arch_domain) to the common-side (struct domain). Ctrl-reg bits (i.e. write_ctrlreg_* members) are left on the arch-side, because control-registers number can vary

[Xen-devel] [PATCH 0/7] Vm-events: move monitor vm-events code to common code.

This patch series is an attempt to move (most) of the monitor vm-events code to the common-side. Patches summary: 1. Move xen/arch/arm/hvm.c to xen/arch/arm/hvm/hvm.c 2. Merge almost identical functions hvm_event_int3 + This patch series is an attempt to move (most) of the monitor vm-events

[Xen-devel] [PATCH 6/7] Rename event_x86.c to event.c and event_arch.h to event.h + minor fixes

* rename arch/x86/hvm/event_x86.c to arch/x86/hvm/event.c and asm-{x86,arm}/hvm/event_arch.h to asm-{x86/arm}/hvm/event.h (last commit before this one explains why this was necessary) Minor fixes: * ARM fix: xen/common/hvm/event.c was not actually compiled (see

[Xen-devel] [PATCH 4/7] Rename monitor_x86.c to monitor.c and monitor_arch.h to monitor.h

(last commit before this one explains why this was necessary) Signed-off-by: Corneliu ZUZU --- xen/arch/x86/Makefile | 2 +- xen/arch/x86/monitor.c | 72 + xen/arch/x86/monitor_x86.c | 72

[Xen-devel] [PATCH 2/7] x86: hvm events: merge 2 functions into 1

This patch merges almost identical functions hvm_event_int3 and hvm_event_single_step into a single function called hvm_event_software_breakpoint. Signed-off-by: Corneliu ZUZU --- xen/arch/x86/hvm/event.c| 52 ++---

Re: [Xen-devel] [PATCH] x86/hvm: simplify emulation triggered by vm_event response

> >> The logic makes sense, so Acked-by: Andrew Cooper > >> for the x86-related nature, but it would be > >> nice to have a review from Tamas for the vm_event side of things. > > > > Thanks! Of course. Hopefully Tamas will like this, based on a > > conversation we've

[Xen-devel] [PATCH 2/2] build: convert xenoprof to Kconfig

Convert the xenoprof x86 build time option to Kconfig. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein --- xen/arch/x86/Makefile | 2 +- xen/arch/x86/Rules.mk | 3 ---

[Xen-devel] [PATCH 1/2] xenoprof: fix up ability to disable it

Allow Xenoprof to be fully disabled when toggling the option off. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper CC: Boris Ostrovsky CC: Suravee Suthikulpanit CC: Aravind

Re: [Xen-devel] [PATCH v2 24/30] tools/libxc: Modify bitmap operations to take void pointers

At 13:42 + on 05 Feb (1454679737), Andrew Cooper wrote: > The type of the pointer to a bitmap is not interesting; it does not affect the > representation of the block of bits being pointed to. It does affect the alignment, though. Is this safe on ARM? Tim.

Re: [Xen-devel] [PATCH v2 24/30] tools/libxc: Modify bitmap operations to take void pointers

On Mon, 2016-02-08 at 16:23 +, Tim Deegan wrote: > At 13:42 + on 05 Feb (1454679737), Andrew Cooper wrote: > > The type of the pointer to a bitmap is not interesting; it does not > > affect the > > representation of the block of bits being pointed to. > > It does affect the alignment,

Re: [Xen-devel] [PATCH v2] xen/arm: correctly handle DMA mapping of compound pages

On Mon, 8 Feb 2016, Ian Campbell wrote: > Currently xen_dma_map_page concludes that DMA to anything other than > the head page of a compound page must be foreign, since the PFN of the > page is that of the head. > > Fix the check to instead consider the whole of a compound page to be > local if

Re: [Xen-devel] Adding Xen to the kbuild bot?

On 2/5/16 2:10 PM, Andy Lutomirski wrote: > On Feb 4, 2016 7:11 PM, "Fengguang Wu" wrote: >> >> Hi Andy, >> >> CC more people on Xen testing -- in case OSStest already (or plans to) >> cover such test case. >> >> On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski

Re: [Xen-devel] [PATCH OSSTEST 5/5 v3] mg-show-flight-runvars: recurse on buildjobs upon request

Ian Campbell writes ("[PATCH OSSTEST 5/5 v3] mg-show-flight-runvars: recurse on buildjobs upon request"): > By looping over @rows looking for buildjobs runvars and adding those > jobs to the output until nothing changes. > > The output is resorted by runvar name which is the desired default >

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 02/08/2016 11:05 AM, Andrew Cooper wrote: For compatibility with other virtualisation specs, Xen's cpuid leaves shift depending on configuration. Spec at

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 16:31, Boris Ostrovsky wrote: > > > On 02/08/2016 11:26 AM, Andrew Cooper wrote: >> On 08/02/16 16:12, Boris Ostrovsky wrote: >>> >>> On 02/08/2016 11:05 AM, Andrew Cooper wrote: For compatibility with other virtualisation specs, Xen's cpuid leaves shift depending on

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote: > I think we are OK for PV because this code will be executed after pvops are > set and so we will be calling xen_cpuid(). Not for the early loader - it is too early for pvops then. So you're saying something like that won't work?

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote: > Does the early loader have extable support? If so, this is fairly easy > to fix. If not, we have a problem. It doesn't and regardless, you want to have this CPUID querying as simple as possible. No special handling, no special

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 02/08/2016 11:45 AM, Borislav Petkov wrote: On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote: Does the early loader have extable support? If so, this is fairly easy to fix. If not, we have a problem. It doesn't and regardless, you want to have this CPUID querying as simple

Re: [Xen-devel] [PATCH] xen/arm: correctly handle DMA mapping of compound pages

On Mon, 2016-02-08 at 15:46 +, Stefano Stabellini wrote: > On Mon, 8 Feb 2016, Ian Campbell wrote: > > Currently xen_dma_map_page concludes that DMA to anything other than > > the head page of a compound page must be foreign, since the PFN of the > > page is that of the head. > > > > Fix the

Re: [Xen-devel] [PATCH 2/2] build: convert xenoprof to Kconfig

On 08/02/16 16:04, Doug Goldstein wrote: > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index 6f404b4..fbb64a7 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -84,6 +84,19 @@ config LATE_HWDOM > > If unsure, say N. > > +# Adds support for Xenoprof > +config

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 16:12, Boris Ostrovsky wrote: > > > On 02/08/2016 11:05 AM, Andrew Cooper wrote: >> >> For compatibility with other virtualisation specs, Xen's cpuid leaves >> shift depending on configuration. >> >> Spec at >>

Re: [Xen-devel] [PATCH 1/7] arm: move arch/arm/hvm.c to arch/arm/hvm/hvm.c

On 08/02/16 16:57, Corneliu ZUZU wrote: > X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry, > also move arch/arm/hvm.c to arch/arm/hvm/hvm.c. > > Signed-off-by: Corneliu ZUZU For future reference, constructing your patches with -M (detect renames)

Re: [Xen-devel] [PATCH] libxc: correct memory range check in domain builder

On Mon, 2016-02-08 at 15:20 +, Anthony PERARD wrote: > On Mon, Feb 08, 2016 at 03:23:52PM +0100, Juergen Gross wrote: > > Commit 81a76e4b12961a9f54f5021809074196dfe6dbba ("libxc: rework of > > domain builder's page table handler") introduced a regression with > > checking the required memory

Re: [Xen-devel] [PATCH v3 1/3] xen-access: minor fixes

On Sat, 2016-02-06 at 13:13 +0200, Razvan Cojocaru wrote: > On 02/05/2016 11:22 PM, Tamas K Lengyel wrote: > > Only copy the VCPU_PAUSED flag to the response. Copy the entire > > mem_access > > struct which is useful and easily forgotten when also testing the > > emulate > > response flags. Turn

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 10:31:36AM -0500, Boris Ostrovsky wrote: > This range is reserved for hypervisors but the only hypervisor that uses it > is Xen PV (lguest doesn't run in 64-bit mode). Yeah, this is mentioned in arch/x86/include/asm/page_64_types.h: /* * Set __PAGE_OFFSET to the most

Re: [Xen-devel] [PATCH] xen/arm: correctly handle DMA mapping of compound pages

On Mon, 8 Feb 2016, Ian Campbell wrote: > Currently xen_dma_map_page concludes that DMA to anything other than > the head page of a compound page must be foreign, since the PFN of the > page is that of the head. > > Fix the check to instead consider the whole of a compound page to be > local if

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 10:39:43AM -0500, Boris Ostrovsky wrote: > It does. Very much IIRC, the problem was not caused by an access to MSR but > rather some sort of address not being available somewhere. See below. > >- microcode application on Xen: we've had this before. The hypervisor >

[Xen-devel] [PATCH v2] xen/arm: correctly handle DMA mapping of compound pages

Currently xen_dma_map_page concludes that DMA to anything other than the head page of a compound page must be foreign, since the PFN of the page is that of the head. Fix the check to instead consider the whole of a compound page to be local if the PFN of the head passes the 1:1 check. We can

Re: [Xen-devel] [PATCH OSSTEST v3 2/2] Add a weekly coverity flight

Ian Campbell writes ("[PATCH OSSTEST v3 2/2] Add a weekly coverity flight"): > This primarily consists of ts-coverity-{build,upload} and > make-coverity-flight which constructs the sole job. Acked-by: Ian Jackson Thanks! Ian.

Re: [Xen-devel] [PATCH 1/2] xenoprof: fix up ability to disable it

On 02/08/2016 11:04 AM, Doug Goldstein wrote: Allow Xenoprof to be fully disabled when toggling the option off. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper CC: Boris Ostrovsky CC: Suravee

Re: [Xen-devel] [PATCH] xl: use bool type for flags instead of int

On Mon, 2016-02-08 at 10:21 +, George Dunlap wrote: > On 06/02/16 02:00, Dario Faggioli wrote: > > in schedulers' command handlers. > > > > No functional change intended. > > > > Signed-off-by: Dario Faggioli > > Acked-by: George Dunlap

Re: [Xen-devel] [PATCH v2 2/2] xen/scsiback: avoid warnings when adding multiple LUNs to a domain

On 02/08/2016 09:30 AM, Juergen Gross wrote: When adding more than one LUN to a frontend a warning for a failed assignment is issued in dom0 for each already existing LUN. Avoid this warning by checking for a LUN already existing when existence is allowed (scsiback_do_add_lun() called with try

Re: [Xen-devel] [PATCH] vm_event: Fix regression caused by b701ccc8

On Mon, 2016-02-08 at 09:39 +, Ian Campbell wrote: > On Fri, 2016-02-05 at 14:20 -0700, Tamas K Lengyel wrote: > > When xc_map_foreign_batch got deprecated reinitializing vm_event on a > > domain > > where an event listener was previously active broke as it relied on the > > flag > >

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 16:35, Borislav Petkov wrote: > On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote: >> I think we are OK for PV because this code will be executed after pvops are >> set and so we will be calling xen_cpuid(). > Not for the early loader - it is too early for pvops then. So

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 16:45, Borislav Petkov wrote: > On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote: >> Does the early loader have extable support? If so, this is fairly easy >> to fix. If not, we have a problem. > It doesn't and regardless, you want to have this CPUID querying as > simple

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 11:41:16AM -0500, Boris Ostrovsky wrote: > Keep in mind that Xen PV doesn't go through startup_32|64(). It starts at > xen_start_kernel (save for a small stub before that), which sets pvops. It > "joins" regular/baremetal code in >

Re: [Xen-devel] [PATCH v1 1/1] XEN/ARM: Add Odroid-XU3/XU4 support

On Mon, Feb 8, 2016 at 7:27 AM, Ian Campbell wrote: > On Sun, 2016-02-07 at 09:44 -0800, Suriyan Ramasami wrote: > > The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board. > > Code from mcpm-exynos.c and mcpm-platsmp.c from the Linux kernel > > has been used

Re: [Xen-devel] [PATCH v2 24/30] tools/libxc: Modify bitmap operations to take void pointers

On 05/02/16 16:12, Wei Liu wrote: > On Fri, Feb 05, 2016 at 01:42:17PM +, Andrew Cooper wrote: >> The type of the pointer to a bitmap is not interesting; it does not affect >> the >> representation of the block of bits being pointed to. >> >> Make the libxc functions consistent with those in

Re: [Xen-devel] Can't create small PV guest anymore (64MB)

On 08/02/16 12:18, Anthony PERARD wrote: > Hi, > > I used to be able to boot a guest with 64MB, but now the minimum required > to boot it seams to be 85MB. It's a PV guest used and lauched by OpenStack > with there test suite. You can find the image at [1]. > > The guest failed to boot with this

Re: [Xen-devel] [PATCH 2/2] xen/scsiback: avoid warnings when adding multiple LUNs to a domain

On 05/02/16 18:24, Boris Ostrovsky wrote: > > > On 02/05/2016 11:59 AM, Juergen Gross wrote: >> On 05/02/16 16:50, Boris Ostrovsky wrote: >>> >>> On 02/05/2016 08:21 AM, Juergen Gross wrote: When adding more than one LUN to a frontend a warning for a failed assignment is issued in dom0

[Xen-devel] [libvirt test] 81092: regressions - FAIL

flight 81092 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/81092/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 80121

Re: [Xen-devel] [PATCH] xl: use bool type for flags instead of int

On 06/02/16 02:00, Dario Faggioli wrote: > in schedulers' command handlers. > > No functional change intended. > > Signed-off-by: Dario Faggioli Acked-by: George Dunlap > --- > Cc: Ian Jackson > Cc: Ian Campbell

Re: [Xen-devel] [PATCH RESEND] fix MSI injection on Xen

On Thu, 4 Feb 2016, Michael S. Tsirkin wrote: > On Thu, Feb 04, 2016 at 05:05:46PM +, Stefano Stabellini wrote: > > Hi Michael, > > > > do you have any comments on this? > > I dislike how it spreads xen specific stuff around, > but I don't have a better idea at the moment, so > I applied

Re: [Xen-devel] [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen

On Sat, 6 Feb 2016, Rafael J. Wysocki wrote: > On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao wrote: > > From: Shannon Zhao > > > > ACPI 6.0 introduces a new table STAO to list the devices which are used > > by Xen and can't be used by Dom0. On

Re: [Xen-devel] Can't create small PV guest anymore (64MB)

On Mon, Feb 08, 2016 at 12:50:43PM +0100, Juergen Gross wrote: > On 08/02/16 12:18, Anthony PERARD wrote: > > Hi, > > > > I used to be able to boot a guest with 64MB, but now the minimum required > > to boot it seams to be 85MB. It's a PV guest used and lauched by OpenStack > > with there test

[Xen-devel] [distros-debian-sid test] 38732: regressions - FAIL

flight 38732 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38732/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-amd64-sid-netboot-pygrub 9 debian-di-install fail REGR. vs. 38718

[Xen-devel] Can't create small PV guest anymore (64MB)

Hi, I used to be able to boot a guest with 64MB, but now the minimum required to boot it seams to be 85MB. It's a PV guest used and lauched by OpenStack with there test suite. You can find the image at [1]. The guest failed to boot with this error message: xc: error: panic: xc_dom_x86.c:147:

Re: [Xen-devel] [PATCH v4 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

On Fri, 5 Feb 2016, Shannon Zhao wrote: > From: Shannon Zhao > > Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could > scan this to get the UEFI information. > > Signed-off-by: Shannon Zhao > Acked-by: Rob Herring

Re: [Xen-devel] [PATCH v7 5/5] PCI: ACPI: Add a generic ACPI based host controller

Lorenzo, On Fri, Feb 5, 2016 at 3:17 PM, Lorenzo Pieralisi wrote: > On Fri, Feb 05, 2016 at 02:05:37PM +0530, Jayachandran Chandrashekaran Nair > wrote: > > [...] > >> pci_host_acpi.c is a generic implementation of these using a sysdata >> pointing to

Re: [Xen-devel] [PATCH v4] xen: sched: convert RTDS from time to event driven model

On Fri, 2016-02-05 at 23:27 -0500, Tianyang Chen wrote: > > On 2/5/2016 9:39 AM, Dario Faggioli wrote: > > On Wed, 2016-02-03 at 21:23 -0500, Tianyang Chen wrote: > > > > I see. So I'm just curious what can cause spurious wakeup? Does it > only  > happen to a running vcpu (currently on pcpu),

Re: [Xen-devel] [PATCH v4 05/17] xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio

On Fri, 5 Feb 2016, Shannon Zhao wrote: > From: Shannon Zhao > > Add a new type of Xen map space for Dom0 to map device's MMIO region. > > Signed-off-by: Shannon Zhao > --- > include/xen/interface/memory.h | 1 + > 1 file changed, 1

Re: [Xen-devel] [PATCH v7 3/5] libxl: add support for vscsi

On Fri, Feb 05, Olaf Hering wrote: > +int xlu_vscsi_detach(XLU_Config *cfg, libxl_ctx *ctx, uint32_t domid, char > *str) > +{ > +if (vc->num_vscsidevs > 1) { > +/* Remove single vscsidev connected to this vscsictrl */; > +ctrl.devid =

Re: [Xen-devel] Can't create small PV guest anymore (64MB)

On 08/02/16 13:06, Anthony PERARD wrote: > On Mon, Feb 08, 2016 at 12:50:43PM +0100, Juergen Gross wrote: >> On 08/02/16 12:18, Anthony PERARD wrote: >>> Hi, >>> >>> I used to be able to boot a guest with 64MB, but now the minimum required >>> to boot it seams to be 85MB. It's a PV guest used and

Re: [Xen-devel] [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

On Fri, 2016-02-05 at 17:48 -0800, Luis R. Rodriguez wrote: > What's up folks? How can this process be made smoother, did I do > something wrong, what can I do to help better? When you first sent this series to Jan + me not copying the list you were asked to send to the list _and_ to CC the

[Xen-devel] [linux-mingo-tip-master test] 81132: regressions - FAIL

flight 81132 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/81132/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684

Re: [Xen-devel] [PATCH] x86/hvm: simplify emulation triggered by vm_event response

On 02/04/2016 02:52 PM, Razvan Cojocaru wrote: > On 02/04/2016 02:36 PM, Andrew Cooper wrote: >> On 04/02/16 12:27, Razvan Cojocaru wrote: >>> Currently, after receiving a vm_event reply requesting emulation, >>> the actual emulation is triggered in p2m_mem_access_check(), >>> which means that

Re: [Xen-devel] HVMlite ABI specification DRAFT A

On Fri, 5 Feb 2016, Andrew Cooper wrote: > The current pci-front/back and Qemu-based methods have substantial > architectural deficiencies, and are incredibly fragile to change. When > was the last XSA to PCI Passthrough which didn't end up requiring > further bugfixes to undo the collateral

Re: [Xen-devel] [PATCH] vm_event: Fix regression caused by b701ccc8

On Fri, 2016-02-05 at 14:20 -0700, Tamas K Lengyel wrote: > When xc_map_foreign_batch got deprecated reinitializing vm_event on a domain > where an event listener was previously active broke as it relied on the flag > XEN_DOMCTL_PFINFO_XTAB to indicate that the magic page is not in the physmap. >

Re: [Xen-devel] [PATCH v5 for Xen 4.7 3/4] libxl: enable per-VCPU parameter settings for RTDS scheduler

On Fri, Feb 05, 2016 at 06:10:33PM -0600, Chong Li wrote: > I'll fix these coding style issues. > Thank you. :-) [...] > >> +num_vcpus = max_vcpuid + 1; > >> +GCNEW_ARRAY(vcpus, num_vcpus); > >> +if (sched_rtds_validate_params(gc, scinfo->vcpus[0].period, > >> +

Re: [Xen-devel] [PATCH 1/2] xenoprof: fix up ability to disable it

On 2/8/16 10:24 AM, Boris Ostrovsky wrote: > > > On 02/08/2016 11:04 AM, Doug Goldstein wrote: >> Allow Xenoprof to be fully disabled when toggling the option off. >> >> CC: Keir Fraser >> CC: Jan Beulich >> CC: Andrew Cooper >> CC:

Re: [Xen-devel] [PATCH 1/2] xenoprof: fix up ability to disable it

On 2/8/16 10:24 AM, Boris Ostrovsky wrote: > > > On 02/08/2016 11:04 AM, Doug Goldstein wrote: >> Allow Xenoprof to be fully disabled when toggling the option off. >> >> CC: Keir Fraser >> CC: Jan Beulich >> CC: Andrew Cooper >> CC:

[Xen-devel] [PATCH v2 2/2] build: convert xenoprof to Kconfig

Convert the xenoprof x86 build time option to Kconfig. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Reviewed-by: Andrew Cooper Signed-off-by: Doug Goldstein --- change since v1: -

[Xen-devel] [PATCH v2 1/2] xenoprof: fix up ability to disable it

Allow Xenoprof to be fully disabled when toggling the option off. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper CC: Boris Ostrovsky CC: Suravee Suthikulpanit CC: Aravind

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 04:53:00PM +, Andrew Cooper wrote: > On 08/02/16 16:45, Borislav Petkov wrote: > > On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote: > >> Does the early loader have extable support? If so, this is fairly easy > >> to fix. If not, we have a problem. > > It

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 10:31:36AM -0500, Boris Ostrovsky wrote: > > > On 02/06/2016 03:05 PM, Andy Lutomirski wrote: > > > >Anyway, this is all ridiculous. I propose that rather than trying to > >clean up paravirt_enabled, you just delete it. Here are its users: > > > >static inline bool

[Xen-devel] [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support

The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board. Code from mcpm-exynos.c and mcpm-platsmp.c from the Linux kernel has been used to get all the 8 cores from the 2 clusters powered on. The Linux DTS for these odroid uses "samsung,exynos5800" as the machine compatible string. Hence,

Re: [Xen-devel] [PATCH 7/7] arch.monitor: move bits to common (arch_domain to domain)

On 2/8/2016 8:29 PM, Tamas K Lengyel wrote: On Mon, Feb 8, 2016 at 9:58 AM, Corneliu ZUZU > wrote: This patch moves bitfield members for single-step, software-breakpoint and guest-request monitor vm-events from the arch-side

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Sat, Feb 06, 2016 at 12:05:32PM -0800, Andy Lutomirski wrote: > On Sat, Feb 6, 2016 at 12:59 AM, Luis R. Rodriguez wrote: > > On Fri, Feb 05, 2016 at 11:11:34PM -0800, Andy Lutomirski wrote: > >> On Feb 5, 2016 8:30 PM, "Luis R. Rodriguez" wrote: > >> > >

Re: [Xen-devel] [PATCH v4 16/17] FDT: Add a helper to get specified name subnode

On Thu, Feb 4, 2016 at 9:05 PM, Shannon Zhao wrote: > From: Shannon Zhao > > Sometimes it needs to check if there is a node in FDT by full path. I'm confused. Are you searching by full path or... > Introduce this helper to get the specified

[Xen-devel] [PATCH v5][RFC]xen: sched: convert RTDS from time to event driven model

Changes since v4: removed unnecessary replenishment queue checks in vcpu_wake() extended replq_remove() to all cases in vcpu_sleep() used _deadline_queue_insert() helper function for both queues _replq_insert() and _replq_remove() program timer internally Changes since v3:

Re: [Xen-devel] [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices

On Mon, Feb 08, 2016 at 06:39:17PM +0100, Marek Marczykowski-Górecki wrote: > On Wed, Feb 03, 2016 at 10:26:58AM -0500, Konrad Rzeszutek Wilk wrote: > > On Wed, Feb 03, 2016 at 03:22:30PM +0100, Marek Marczykowski-Górecki wrote: > > > On Mon, Feb 01, 2016 at 09:50:53AM -0500, Konrad Rzeszutek Wilk

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 04:46:08PM +0100, Borislav Petkov wrote: > On Mon, Feb 08, 2016 at 10:31:36AM -0500, Boris Ostrovsky wrote: > > This range is reserved for hypervisors but the only hypervisor that uses it > > is Xen PV (lguest doesn't run in 64-bit mode). > > Yeah, this is mentioned in

Re: [Xen-devel] HVMlite ABI specification DRAFT A

On 08/02/16 12:10, Stefano Stabellini wrote: > On Fri, 5 Feb 2016, Andrew Cooper wrote: >> The current pci-front/back and Qemu-based methods have substantial >> architectural deficiencies, and are incredibly fragile to change. When >> was the last XSA to PCI Passthrough which didn't end up

[Xen-devel] [PATCH] xen/arm: correctly handle DMA mapping of compound pages

Currently xen_dma_map_page concludes that DMA to anything other than the head page of a compound page must be foreign, since the PFN of the page is that of the head. Fix the check to instead consider the whole of a compound page to be local if the PFN of the head passes the 1:1 check. We can

Re: [Xen-devel] [PATCH v1 1/1] XEN/ARM: Add Odroid-XU3/XU4 support

On Sun, 2016-02-07 at 09:44 -0800, Suriyan Ramasami wrote: > The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board. > Code from mcpm-exynos.c and mcpm-platsmp.c from the Linux kernel > has been used to get all the 8 cores from the 2 clusters powered > on. > The Linux DTS for these

Re: [Xen-devel] deprecating pvgrub (grub-legacy)

On 2/8/16 7:26 AM, David Vrabel wrote: > On 06/02/16 21:38, Doug Goldstein wrote: >> Hi all, >> >> Given that pvgrub2 has been available for a while now and Ian did a good >> write up on the Xen blog of how to use it and a few downstream distros >> are starting to pick it up as the way to boot Xen

[Xen-devel] [PATCH v2 0/2] xen/scsiback: correct two issues

Correct two issues in the Xen pvscsi backend. Changes in V2: - Patch 2: scsiback_del_translation_entry() returns error code instead of 1 (Boris Ostrovsky) Juergen Gross (2): xen/scsiback: correct frontend counting xen/scsiback: avoid warnings when adding multiple LUNs to a domain

[Xen-devel] [PATCH v2 2/2] xen/scsiback: avoid warnings when adding multiple LUNs to a domain

When adding more than one LUN to a frontend a warning for a failed assignment is issued in dom0 for each already existing LUN. Avoid this warning by checking for a LUN already existing when existence is allowed (scsiback_do_add_lun() called with try == 1). As the LUN existence check is needed now

[Xen-devel] [PATCH v2 1/2] xen/scsiback: correct frontend counting

When adding a new frontend to xen-scsiback don't decrement the number of active frontends in case of no error. Doing so results in a failure when trying to remove the xen-pvscsi nexus even if no domain is using it. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 02/06/2016 03:05 PM, Andy Lutomirski wrote: Anyway, this is all ridiculous. I propose that rather than trying to clean up paravirt_enabled, you just delete it. Here are its users: static inline bool is_hypervisor_range(int idx) { /* * 8000 - 87ff is

Re: [Xen-devel] deprecating pvgrub (grub-legacy)

On 06/02/16 21:38, Doug Goldstein wrote: > Hi all, > > Given that pvgrub2 has been available for a while now and Ian did a good > write up on the Xen blog of how to use it and a few downstream distros > are starting to pick it up as the way to boot Xen images. Plus most > downstreams switching

Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API

George Dunlap writes ("Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API"): > There's a difference between "making it intelligent" and "not making it > broken". :-) Given that users can potentially cause a number of these > things to fail just by pressing Ctrl-C, we need to at least make sure

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 02/06/2016 05:04 PM, Borislav Petkov wrote: On Sat, Feb 06, 2016 at 12:05:32PM -0800, Andy Lutomirski wrote: int __init microcode_init(void) { [...] if (paravirt_enabled() || dis_ucode_ldr) return -EINVAL; This is also asking "are we the natively booted

[Xen-devel] [PATCH] libxc: correct memory range check in domain builder

Commit 81a76e4b12961a9f54f5021809074196dfe6dbba ("libxc: rework of domain builder's page table handler") introduced a regression with checking the required memory size of the domain. The needed maximum pfn of the initial kernel mapping was added to the currently last used pfn resulting in doubling

Re: [Xen-devel] [PATCH] libxc: correct memory range check in domain builder

On Mon, Feb 08, 2016 at 03:23:52PM +0100, Juergen Gross wrote: > Commit 81a76e4b12961a9f54f5021809074196dfe6dbba ("libxc: rework of > domain builder's page table handler") introduced a regression with > checking the required memory size of the domain. The needed maximum pfn > of the initial kernel

[Xen-devel] [PATCH] xen: sched: get rid of static private schedulers' structures

In fact, they look rather useless: they are never referenced neither directly, nor via the sched_data pointer, as a dynamic copy that overrides them is allocated as the very first step of a scheduler's initialization. While there, take the chance to also reset the sched_data pointer to NULL, upon

Re: [Xen-devel] [PATCH] x86/nHVM: avoid NULL deref during INVLPG intercept handling

On 05/02/16 07:37, Jan Beulich wrote: > When intercepting (or emulating) L1 guest INVLPG, the nested P2M > pointer may be (is?) NULL, and hence there's no point in calling > p2m_flush(). In fact doing so would cause a dereference of that NULL > pointer at least in the ASSERT() right at the

Re: [Xen-devel] [PATCH v3 3/3] altp2m: Implement p2m_get_mem_access for altp2m views

On Fri, 2016-02-05 at 14:22 -0700, Tamas K Lengyel wrote: > Extend the existing get_mem_access memop to allow querying permissions in > altp2m views as well. > > Signed-off-by: Tamas K Lengyel > Cc: Ian Jackson > Cc: Stefano Stabellini

Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API

On 04/02/16 14:39, Juergen Gross wrote: > On 04/02/16 02:53, Chun Yan Liu wrote: >> >> > On 2/3/2016 at 10:33 PM, in message <56b20fcc.3010...@citrix.com>, George >> Dunlap wrote: >>> On 02/02/16 18:11, Ian Jackson wrote: George Dunlap writes ("Re: [Xen-devel]

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

flight 81161 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/81161/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 59254

  1   2   >