[Xen-devel] [linux-3.18 bisection] complete test-amd64-i386-xl-qemut-win7-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemut-win7-amd64 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

[Xen-devel] [qemu-mainline baseline-only test] 68261: regressions - FAIL

This run is configured for baseline tests only. flight 68261 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68261/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 10

Re: [Xen-devel] [PATCH] tpm: Restore functionality to xen vtpm driver.

On Thu, Dec 22, 2016 at 02:41:52PM -0600, Dr. Greg Wettstein wrote: > Functionality of the xen-tpmfront driver was lost secondary to > the introduction of xenbus multi-page support in the following > commit: > > ccc9d90a9a8b5c4ad7e9708ec41f75ff9e98d61d > > xenbus_client: Extend interface to

[Xen-devel] [linux-4.1 test] 103799: regressions - FAIL

flight 103799 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103799/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 101737

Re: [Xen-devel] [PATCH 01/10] x86/MSR: introduce MSR access split/fold helpers

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Tuesday, December 20, 2016 6:36 PM > > This is in preparation of eliminating the mis-naming of 64-bit fields > with 32-bit register names (eflags instead of rflags etc). Use the > guaranteed 32-bit underscore prefixed names for now where

Re: [Xen-devel] [PATCH 2/2] x86/VMX: don't needlessly install VMFUNC emulation hook

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, December 22, 2016 11:37 PM > > >>> On 22.12.16 at 16:14, wrote: > > On 22/12/16 14:58, Jan Beulich wrote: > > On 22.12.16 at 15:31, wrote: > >> On 22.12.16 at 14:47,

[Xen-devel] [xen-4.6-testing baseline-only test] 68260: tolerable FAIL

This run is configured for baseline tests only. flight 68260 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68260/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-xtf-amd64-amd64-5 20

Re: [Xen-devel] [PATCH] libxl/libxl_qmp.c: Fix code style in qmp_next()

On 12/22/2016 06:47 PM, Wei Liu wrote: Also CC Anthony, who wrote the original code. On Thu, Dec 22, 2016 at 05:53:07PM +0800, Zhang Chen wrote: Make select loop more readable. The behaviour of this function is changed. The changes are not necessarily wrong, but we need to have clear commit

Re: [Xen-devel] [PATCH 1/2] x86/HVM: constify VMFUNC emulation hook

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, December 22, 2016 4:37 PM > > ... to clarify that the register state does not get altered (behind the > back of the emulator). > > Signed-off-by: Jan Beulich > Acked-by: Kevin Tian

[Xen-devel] [ovmf test] 103801: all pass - PUSHED

flight 103801 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/103801/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 413535bb33d60417d681725af0274086630e7987 baseline version: ovmf

[Xen-devel] [ovmf baseline-only test] 68258: tolerable FAIL

This run is configured for baseline tests only. flight 68258 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68258/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install

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

flight 103798 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/103798/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 103479 Regressions which are

[Xen-devel] [qemu-mainline test] 103797: tolerable FAIL - PUSHED

flight 103797 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/103797/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 103397

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

On Thu, Dec 22, 2016 at 2:11 PM, Alistair Francis wrote: > On Thu, Dec 22, 2016 at 2:00 PM, Doug Goldstein wrote: >> On 12/22/16 3:47 PM, Andrew Cooper wrote: >>> On 22/12/16 21:41, Alistair Francis wrote: On Thu, Dec 22, 2016 at 1:15 PM,

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

On Thu, Dec 22, 2016 at 2:00 PM, Doug Goldstein wrote: > On 12/22/16 3:47 PM, Andrew Cooper wrote: >> On 22/12/16 21:41, Alistair Francis wrote: >>> On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis >>> wrote: On Thu, Dec 22, 2016 at 1:12 PM,

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

On 12/22/16 3:47 PM, Andrew Cooper wrote: > On 22/12/16 21:41, Alistair Francis wrote: >> On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis >> wrote: >>> On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis >>> wrote: On Thu, Dec 22,

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

On 22/12/16 21:41, Alistair Francis wrote: On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis wrote: On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis wrote: On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis wrote: > On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis > wrote: >> On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson >> wrote: >>> Alistair Francis writes

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis wrote: > On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson > wrote: >> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded >> strict -Werror checking"): >>> On Thu, Dec

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson wrote: > Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded > strict -Werror checking"): >> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich wrote: >>> On 20.12.16 at 20:46,

[Xen-devel] [PATCH] tpm: Restore functionality to xen vtpm driver.

Functionality of the xen-tpmfront driver was lost secondary to the introduction of xenbus multi-page support in the following commit: ccc9d90a9a8b5c4ad7e9708ec41f75ff9e98d61d xenbus_client: Extend interface to support multi-page ring In this commit a pointer to the shared page address was being

[Xen-devel] [xen-4.4-testing test] 103796: regressions - FAIL

flight 103796 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103796/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 103782

[Xen-devel] Bug report

Hi my name is Richard and i suscribe to this list but dont know if this list is for reports bugs. Tnks ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking"): > On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich wrote: >> On 20.12.16 at 20:46, wrote: > >> Signed-off-by: Alistair Francis

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich wrote: On 20.12.16 at 20:46, wrote: >> Signed-off-by: Alistair Francis > > Without some rationale given I don't think such changes are > acceptable at all. And then,

Re: [Xen-devel] [PATCH] docs: Clarify scope of reboot= and noreboot Xen command line options

Jan Beulich writes ("Re: [PATCH] docs: Clarify scope of reboot= and noreboot Xen command line options"): > On 22.12.16 at 16:02, wrote: > > -Specify the host reboot method. > > +Specify the host reboot method, > > +used when Xen crashes. > > +(This does not affect

[Xen-devel] [xen-4.6-testing test] 103795: tolerable FAIL - PUSHED

flight 103795 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103795/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103753

[Xen-devel] [RFC PATCH v2 22/26] ARM: vITS: handle INV command

The INV command instructs the ITS to update the configuration data for a given LPI by re-reading its entry from the property table. We don't need to care so much about the priority value, but enabling or disabling an LPI has some effect: We remove or push virtual LPIs to their VCPUs, also check

[Xen-devel] [RFC PATCH v2 26/26] ARM: vGIC: advertising LPI support

To let a guest know about the availability of virtual LPIs, set the respective bits in the virtual GIC registers and let a guest control the LPI enable bit. Only report the LPI capability if the host has initialized at least one ITS. Signed-off-by: Andre Przywara ---

[Xen-devel] [RFC PATCH v2 06/26] ARM: GICv3 ITS: introduce device mapping

The ITS uses device IDs to map LPIs to a device. Dom0 will later use those IDs, which we directly pass on to the host. For this we have to map each device that Dom0 may request to a host ITS device with the same identifier. Allocate the respective memory and enter each device into a list to later

[Xen-devel] [RFC PATCH v2 21/26] ARM: vITS: handle DISCARD command

The DISCARD command drops the connection between a DeviceID/EventID and an LPI/collection pair. We mark the respective structure entries as not allocated and make sure that any queued IRQs are removed. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-its.c | 41

[Xen-devel] [RFC PATCH v2 25/26] ARM: vITS: create ITS subnodes for Dom0 DT

Dom0 expects all ITSes in the system to be propagated to be able to use MSIs. Create Dom0 DT nodes for each hardware ITS, keeping the register frame address the same, as the doorbell address that the Dom0 drivers program into the BARs has to match the hardware. Signed-off-by: Andre Przywara

[Xen-devel] [RFC PATCH v2 10/26] ARM: GICv3: forward pending LPIs to guests

Upon receiving an LPI, we need to find the right VCPU and virtual IRQ number to get this IRQ injected. Iterate our two-level LPI table to find this information quickly when the host takes an LPI. Call the existing injection function to let the GIC emulation deal with this interrupt.

[Xen-devel] [RFC PATCH v2 24/26] ARM: vITS: create and initialize virtual ITSes for Dom0

For each hardware ITS create and initialize a virtual ITS for Dom0. We use the same memory mapped address to keep the doorbell working. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-its.c | 22 ++ xen/arch/arm/vgic-v3.c| 12

[Xen-devel] [RFC PATCH v2 23/26] ARM: vITS: handle INVALL command

The INVALL command instructs an ITS to invalidate the configuration data for all LPIs associated with a given redistributor (read: VCPU). This is nasty to emulate exactly with our architecture, so we just scan the pending table and inject _every_ LPI found there that got enabled. Signed-off-by:

[Xen-devel] [RFC PATCH v2 08/26] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

To get MSIs from devices forwarded to a CPU, we need to name the device and its MSIs by mapping them to an ITS. Since this involves queueing commands to the ITS command queue, we can't really afford to do this during the guest's runtime, as this would open up a denial-of-service attack vector. So

[Xen-devel] [RFC PATCH v2 20/26] ARM: vITS: handle MOVI command

The MOVI command moves the interrupt affinity from one redistributor (read: VCPU) to another. For now migration of "live" LPIs is not yet implemented, but we store the changed affinity in the host LPI structure and in our virtual ITTE. Signed-off-by: Andre Przywara ---

[Xen-devel] [RFC PATCH v2 02/26] ARM: GICv3: allocate LPI pending and property table

The ARM GICv3 ITS provides a new kind of interrupt called LPIs. The pending bits and the configuration data (priority, enable bits) for those LPIs are stored in tables in normal memory, which software has to provide to the hardware. Allocate the required memory, initialize it and hand it over to

[Xen-devel] [RFC PATCH v2 01/26] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT

Parse the DT GIC subnodes to find every ITS MSI controller the hardware offers. Store that information in a list to both propagate all of them later to Dom0, but also to be able to iterate over all ITSes. This introduces an ITS Kconfig option. Signed-off-by: Andre Przywara

[Xen-devel] [RFC PATCH v2 14/26] ARM: vGICv3: introduce basic ITS emulation bits

Create a new file to hold the emulation code for the ITS widget. For now we emulate the memory mapped ITS registers and provide a stub to introduce the ITS command handling framework (but without actually emulating any commands at this time). Signed-off-by: Andre Przywara

[Xen-devel] [RFC PATCH v2 19/26] ARM: vITS: handle MAPTI command

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU pair and actually instantiates LPI interrupts. We connect the already allocated host LPI to this virtual LPI, so that any triggering IRQ on the host can be quickly forwarded to a guest. Signed-off-by: Andre Przywara

[Xen-devel] [RFC PATCH v2 13/26] ARM: vGICv3: Handle disabled LPIs

If a guest disables an LPI, we do not forward this to the associated host LPI to avoid queueing commands to the host ITS command queue. So it may happen that an LPI fires nevertheless on the host. In this case we can bail out early, but have to save the pending state on the virtual side.

[Xen-devel] [RFC PATCH v2 18/26] ARM: vITS: handle MAPD command

The MAPD command maps a device by associating a memory region for storing ITTEs with a certain device ID. We just store the given guest physical address in the device table. We don't map the device tables permanently, as their alignment requirement is only 256 Bytes, thus making mapping of several

[Xen-devel] [RFC PATCH v2 16/26] ARM: vITS: handle INT command

The INT command sets a given LPI identified by a DeviceID/EventID pair as pending and thus triggers it to be injected. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-its.c | 38 ++ 1 file changed, 38 insertions(+) diff --git

[Xen-devel] [RFC PATCH v2 15/26] ARM: vITS: handle CLEAR command

This introduces the ITS command handler for the CLEAR command, which clears the pending state of an LPI. This removes a not-yet injected, but already queued IRQ from a VCPU. In addition this patch introduces the lookup function which translates a given DeviceID/EventID pair into a pointer to our

[Xen-devel] [RFC PATCH v2 04/26] ARM: GICv3 ITS: map ITS command buffer

Instead of directly manipulating the tables in memory, an ITS driver sends commands via a ring buffer to the ITS h/w to create or alter the LPI mappings. Allocate memory for that buffer and tell the ITS about it to be able to send ITS commands. Signed-off-by: Andre Przywara

[Xen-devel] [RFC PATCH v2 00/26] arm64: Dom0 ITS emulation

Hi, this is a reworked version of the Dom0 GICv3-ITS emulation series. This is still not fully where I want it and has some loose bits and pieces still, but since there are significant changes in the architecture I wanted to have an opinion before going ahead and replacing every single number

[Xen-devel] [RFC PATCH v2 17/26] ARM: vITS: handle MAPC command

The MAPC command associates a given collection ID with a given redistributor, thus mapping collections to VCPUs. We just store the vcpu_id in the collection table for that. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-its.c | 30 ++ 1

[Xen-devel] [RFC PATCH v2 12/26] ARM: vGICv3: handle virtual LPI pending and property tables

Allow a guest to provide the address and size for the memory regions it has reserved for the GICv3 pending and property tables. We sanitise the various fields of the respective redistributor registers and map those pages into Xen's address space to have easy access. Signed-off-by: Andre Przywara

[Xen-devel] [RFC PATCH v2 07/26] ARM: GICv3 ITS: introduce host LPI array

The number of LPIs on a host can be potentially huge (millions), although in practise will be mostly reasonable. So prematurely allocating an array of struct irq_desc's for each LPI is not an option. However Xen itself does not care about LPIs, as every LPI will be injected into a guest (Dom0 for

[Xen-devel] [RFC PATCH v2 11/26] ARM: GICv3: enable ITS and LPIs on the host

Now that the host part of the ITS code is in place, we can enable the ITS and also LPIs on each redistributor to get the show rolling. At this point there would be no LPIs mapped, as guests don't know about the ITS yet. Signed-off-by: Andre Przywara ---

[Xen-devel] [RFC PATCH v2 03/26] ARM: GICv3 ITS: allocate device and collection table

Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a pair of LPI number and collection ID, which points to the target CPU. This mapping is stored in the device and collection tables, which software has to provide for the ITS to

[Xen-devel] [RFC PATCH v2 09/26] ARM: GICv3: introduce separate pending_irq structs for LPIs

For the same reason that allocating a struct irq_desc for each possible LPI is not an option, having a struct pending_irq for each LPI is also not feasible. However we actually only need those when an interrupt is on a vCPU (or is about to be injected). Maintain a list of those structs that we can

[Xen-devel] [RFC PATCH v2 05/26] ARM: GICv3 ITS: introduce ITS command handling

To be able to easily send commands to the ITS, create the respective wrapper functions, which take care of the ring buffer. The first two commands we implement provide methods to map a collection to a redistributor (aka host core) and to flush the command queue (SYNC). Start using these commands

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

On 12/22/2016 11:44 AM, Roger Pau Monne wrote: > On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote: > On 22.12.16 at 17:17, wrote: >>> On 12/22/2016 07:17 AM, Roger Pau Monne wrote: Maybe Boris has some ideas about how to do CPU hotplug for Dom0? >>>

Re: [Xen-devel] [PATCH] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness

Jan Beulich writes ("Re: [PATCH] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness"): > On 22.12.16 at 16:10, wrote: > > I did not find this important build fix for a regression in 4.8.0 > > because: > > I wonder why you consider this important -

Re: [Xen-devel] [PATCH 2/2] x86emul: correct 64-bit mode repeated string insn handling with zero count

On 07/12/16 10:22, Jan Beulich wrote: On 06.12.16 at 17:35, wrote: On 06/12/16 13:39, Jan Beulich wrote: @@ -5424,7 +5436,6 @@ x86_emulate( goto cannot_emulate; } - writeback: This removal highlights that the writeback and no_writeback lables are

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote: > >>> On 22.12.16 at 17:17, wrote: > > On 12/22/2016 07:17 AM, Roger Pau Monne wrote: > >> Maybe Boris has some ideas about how to do CPU hotplug for Dom0? > > > > Why would Xen need to be able to parse the

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

flight 103808 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/103808/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

>>> On 22.12.16 at 17:17, wrote: > On 12/22/2016 07:17 AM, Roger Pau Monne wrote: >> Maybe Boris has some ideas about how to do CPU hotplug for Dom0? > > Why would Xen need to be able to parse the AML that is intended to be > executed by dom0? I'd think that all the

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

On 12/22/2016 07:17 AM, Roger Pau Monne wrote: > On Thu, Dec 22, 2016 at 04:03:12AM -0700, Jan Beulich wrote: > On 22.12.16 at 11:43, wrote: >>> On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote: > Since Xen is the one that sets the local APIC address in

Re: [Xen-devel] [PATCH v4 03/24] x86: refactor psr: implement main data structures.

>>> On 14.12.16 at 05:07, wrote: > To construct an extendible framework, we need analyze PSR features > and abstract the common things and feature specific things. Then, > encapsulate them into different data structures. > > By analyzing PSR features, we can get below

Re: [Xen-devel] [PATCH 08/10] x86/vm-event: use unambiguous register names

On 12/20/2016 12:42 PM, Jan Beulich wrote: > This is in preparation of eliminating the mis-naming of 64-bit fields > with 32-bit register names (eflags instead of rflags etc). > > Signed-off-by: Jan Beulich Acked-by: Razvan Cojocaru Thanks,

Re: [Xen-devel] [PATCH v4 02/24] x86: refactor psr: remove L3 CAT/CDP codes.

>>> On 14.12.16 at 05:07, wrote: > The current cache allocation codes in psr.c do not consider > future features addition and are not friendly to extend. > > To make psr.c be more flexible to add new features and fulfill > the program principle, open for extension but

Re: [Xen-devel] [PATCH 2/3] xen: return xenstore command failures via response instead of rc

On 12/22/2016 10:55 AM, Juergen Gross wrote: > On 22/12/16 16:49, Boris Ostrovsky wrote: >> On 12/22/2016 02:19 AM, Juergen Gross wrote: >>> When the xenbus driver does some special handling for a Xenstore >>> command any error condition related to the command should be returned >>> via an error

Re: [Xen-devel] [PATCH 2/3] xen: return xenstore command failures via response instead of rc

On 22/12/16 16:49, Boris Ostrovsky wrote: > On 12/22/2016 02:19 AM, Juergen Gross wrote: >> When the xenbus driver does some special handling for a Xenstore >> command any error condition related to the command should be returned >> via an error response instead of letting the related write

Re: [Xen-devel] [PATCH 1/3] xen: xenbus driver must not accept invalid transaction ids

On 22/12/16 16:38, Boris Ostrovsky wrote: > On 12/22/2016 02:19 AM, Juergen Gross wrote: >> When accessing Xenstore in a transaction the user is specifying a >> transaction id which he normally obtained from Xenstore when starting >> the transaction. Xenstore is validating a transaction id against

Re: [Xen-devel] [PATCH 3/3] xen: remove stale xs_input_avail() from header

On 12/22/2016 02:19 AM, Juergen Gross wrote: > In drivers/xen/xenbus/xenbus_comms.h there is a stale declaration of > xs_input_avail(). Remove it. > > Signed-off-by: Juergen Gross > Reviewed-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH 2/3] xen: return xenstore command failures via response instead of rc

On 12/22/2016 02:19 AM, Juergen Gross wrote: > When the xenbus driver does some special handling for a Xenstore > command any error condition related to the command should be returned > via an error response instead of letting the related write operation > fail. Otherwise the user land handler

Re: [Xen-devel] [PATCH v2 5/5] tools/blktap2/drivers: Remove non-existent sys/sysctl.h include

On 12/20/16 1:47 PM, Alistair Francis wrote: > To avoid build errors related to missing file 'sys/sysctl.h' by removing > the #include statement. > > Signed-off-by: Alistair Francis > --- > tools/blktap2/drivers/block-remus.c | 1 - > 1 file changed, 1 deletion(-) >

Re: [Xen-devel] [PATCH v2 5/5] tools/blktap2/drivers: Remove non-existent sys/sysctl.h include

On Thu, Dec 22, 2016 at 2:54 AM, Wei Liu wrote: > On Tue, Dec 20, 2016 at 11:47:00AM -0800, Alistair Francis wrote: >> To avoid build errors related to missing file 'sys/sysctl.h' by removing >> the #include statement. >> >> Signed-off-by: Alistair Francis

Re: [Xen-devel] [PATCH 1/3] xen: xenbus driver must not accept invalid transaction ids

On 12/22/2016 02:19 AM, Juergen Gross wrote: > When accessing Xenstore in a transaction the user is specifying a > transaction id which he normally obtained from Xenstore when starting > the transaction. Xenstore is validating a transaction id against all > known transaction ids of the connection

Re: [Xen-devel] [PATCH 2/2] x86/VMX: don't needlessly install VMFUNC emulation hook

>>> On 22.12.16 at 16:14, wrote: > On 22/12/16 14:58, Jan Beulich wrote: > On 22.12.16 at 15:31, wrote: >> On 22.12.16 at 14:47, wrote: On 22/12/16 08:37, Jan Beulich wrote: > Instead of checking

Re: [Xen-devel] [PATCH] xsm: allow relevant permission during migrate and gpu-passthrough.

>>> On 22.12.16 at 16:28, wrote: > On 12/20/16 3:37 AM, Anshul Makkar wrote: >> On 20/12/2016 04:03, Doug Goldstein wrote: >>> On 12/19/16 10:02 AM, Doug Goldstein wrote: On 12/14/16 3:09 PM, Daniel De Graaf wrote: > On 12/12/2016 09:00 AM, Anshul Makkar wrote: >>

Re: [Xen-devel] [PATCH] docs: Clarify scope of reboot= and noreboot Xen command line options

>>> On 22.12.16 at 16:02, wrote: > @@ -1356,7 +1357,9 @@ The following resources are available: > > > Default: `0` > > -Specify the host reboot method. > +Specify the host reboot method, > +used when Xen crashes. > +(This does not affect deliberate reboots

Re: [Xen-devel] [PATCH] xsm: allow relevant permission during migrate and gpu-passthrough.

On 12/20/16 3:37 AM, Anshul Makkar wrote: > On 20/12/2016 04:03, Doug Goldstein wrote: >> On 12/19/16 10:02 AM, Doug Goldstein wrote: >>> On 12/14/16 3:09 PM, Daniel De Graaf wrote: On 12/12/2016 09:00 AM, Anshul Makkar wrote: > During guest migrate allow permission to prevent >

Re: [Xen-devel] [PATCH] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness

>>> On 22.12.16 at 16:10, wrote: > I did not find this important build fix for a regression in 4.8.0 > because: I wonder why you consider this important - the harness doesn't get built by default, and is of little use for other than smoke testing a limited set of

[Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

Create a basic Makefile to build and install libxenlight Golang bindings. Also add a stub package. --- Eventually this patch will contain the actual bindings package; for now it just includes a stub package. To Do: - Have configure detect golang bindings properly CC: xen-devel

Re: [Xen-devel] [PATCH] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness

Andrew Cooper writes ("Re: [PATCH] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness"): > On 22/12/16 14:58, Ian Jackson wrote: > > "x86emul: in_longmode() should not ignore ->read_msr() errors" aka > > c/s 122dd9575c7a introduced a use of unlikely() in > >

Re: [Xen-devel] [PATCH 2/2] x86/VMX: don't needlessly install VMFUNC emulation hook

On 22/12/16 14:58, Jan Beulich wrote: On 22.12.16 at 15:31, wrote: On 22.12.16 at 14:47, wrote: On 22/12/16 08:37, Jan Beulich wrote: Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to determine whether to install the hook in the

[Xen-devel] [PATCH] docs: Clarify scope of reboot= and noreboot Xen command line options

Signed-off-by: Ian Jackson CC: Jan Beulich --- docs/misc/xen-command-line.markdown | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index

Re: [Xen-devel] [PATCH] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness

On 22/12/16 14:58, Ian Jackson wrote: "x86emul: in_longmode() should not ignore ->read_msr() errors" aka c/s 122dd9575c7a introduced a use of unlikely() in xen/arch/x86/x86_emulate/x86_emulate.c. I think this is probably intentional and fine. However, there is no definition of unlikely in the

[Xen-devel] [PATCH] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness

"x86emul: in_longmode() should not ignore ->read_msr() errors" aka c/s 122dd9575c7a introduced a use of unlikely() in xen/arch/x86/x86_emulate/x86_emulate.c. I think this is probably intentional and fine. However, there is no definition of unlikely in the x86 emulator test harness, under tools.

Re: [Xen-devel] [PATCH 2/2] x86/VMX: don't needlessly install VMFUNC emulation hook

>>> On 22.12.16 at 15:31, wrote: On 22.12.16 at 14:47, wrote: >> On 22/12/16 08:37, Jan Beulich wrote: >>> Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to >>> determine whether to install the hook in the first place. >>> >>>

Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)

>>> On 22.12.16 at 14:47, wrote: > Jan Beulich writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] > 103788: regressions - trouble: broken/fail/pass)"): >> On 22.12.16 at 13:19, wrote: >> > Perhaps it would be worth telling Xen

Re: [Xen-devel] [BUG] Xen-4.8.0 efi/buildid.o: file not recognized/Ambiguous

>>> On 07.12.16 at 16:57, wrote: > efi/buildid.o: file not recognized: File format is ambiguous > efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 Just fyi: After some analysis of the binutils sources I have come to the conclusion that this needs help from

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

flight 103806 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/103806/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

[Xen-devel] [distros-debian-wheezy test] 68259: all pass

flight 68259 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68259/ Perfect :-) All tests in this flight passed as required baseline version: flight 68223 jobs: build-amd64 pass

Re: [Xen-devel] [PATCH 2/2] x86/VMX: don't needlessly install VMFUNC emulation hook

>>> On 22.12.16 at 14:47, wrote: > On 22/12/16 08:37, Jan Beulich wrote: >> Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to >> determine whether to install the hook in the first place. >> >> Signed-off-by: Jan Beulich > > I am not

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

flight 103792 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103792/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-13 host-install(3)broken REGR. vs.

Re: [Xen-devel] [PATCH v5 09/14] jump_label: port __jump_table to linker tables

On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote: > Move the __jump_table from the a custom section solution > to a generic solution, this avoiding extra vmlinux.lds.h > customizations. > > This also demos the use of the .data linker table and of > the shared asm call

Re: [Xen-devel] [PATCH v5 04/14] tables.h: add linker table support

On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote: > A linker table is a data structure that is stitched together from > items > in multiple object files. Linux has historically implicitly used > linker > tables for ages, however they were all built in an adhoc manner which > requires

Re: [Xen-devel] Xenstore watch interface in the kernel

Sander Eikelenboom writes ("Re: [Xen-devel] Xenstore watch interface in the kernel"): > Something I did ran into while trying to use xenstore, was that the > callbacks don't give back the previous and current value. Others have replied to this, and I agree with them, but: this makes me think you

Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)

Jan Beulich writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)"): > On 22.12.16 at 13:19, wrote: > > Perhaps it would be worth telling Xen not to reboot on crash... > > I think that's worth giving a try (I

Re: [Xen-devel] [PATCH 2/2] x86/VMX: don't needlessly install VMFUNC emulation hook

On 22/12/16 08:37, Jan Beulich wrote: Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to determine whether to install the hook in the first place. Signed-off-by: Jan Beulich I am not so sure about this. vmfunc is reachable in the instruction emulator on

Re: [Xen-devel] [PATCH 1/2] x86/HVM: constify VMFUNC emulation hook

On 22/12/16 08:36, Jan Beulich wrote: ... to clarify that the register state does not get altered (behind the back of the emulator). Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel

Re: [Xen-devel] Xenstore watch interface in the kernel

On 22/12/16 12:59, Juergen Gross wrote: On 22/12/16 13:49, Sander Eikelenboom wrote: Thursday, December 22, 2016, 1:22:06 PM, you wrote: Juergen Gross writes ("Xenstore watch interface in the kernel"): While working on the Linux xenbus kernel driver I stumbled over a rather strange

Re: [Xen-devel] [PATCH v15] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

On December 22, 2016 2:21:26 AM EST, Oleksandr Andrushchenko wrote: >Hi, Konrad! > >I see no comments for almost 3 weeks now, so >probably there are no objections against this protocol. >Can we please move on on this? Sorry, I had been busy with internal high priority items.

Re: [Xen-devel] Xenstore watch interface in the kernel

On 22/12/16 13:49, Sander Eikelenboom wrote: > > Thursday, December 22, 2016, 1:22:06 PM, you wrote: > >> Juergen Gross writes ("Xenstore watch interface in the kernel"): >>> While working on the Linux xenbus kernel driver I stumbled over a rather >>> strange interface: a Xenstore watch event is

Re: [Xen-devel] Xenstore watch interface in the kernel

Thursday, December 22, 2016, 1:22:06 PM, you wrote: > Juergen Gross writes ("Xenstore watch interface in the kernel"): >> While working on the Linux xenbus kernel driver I stumbled over a rather >> strange interface: a Xenstore watch event is delivered via a callback >> defined as: >> >> void

  1   2   >