Re: [Xen-devel] [PATCH 17/33] xen/scsiback: Make TMF processing slightly faster

On Tue, 2017-05-23 at 16:48 -0700, Bart Van Assche wrote: > Target drivers must guarantee that struct se_cmd and struct se_tmr_req > exist as long as target_tmr_work() is in progress. Since the last > access by the LIO core is a call to .check_stop_free() and since the > Xen scsiback

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

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

Re: [Xen-devel] [PATCH 15/33] xen/scsiback: Fix a use-after-free

On Tue, 2017-05-23 at 16:48 -0700, Bart Van Assche wrote: > scsiback_release_cmd() must not dereference se_cmd->se_tmr_req > because that memory is freed by target_free_cmd_mem() before > scsiback_release_cmd() is called. Fix this use-after-free by > inlining struct scsiback_tmr into struct

Re: [Xen-devel] [PATCH 16/33] xen/scsiback: Replace a waitqueue and a counter by a completion

On Tue, 2017-05-23 at 16:48 -0700, Bart Van Assche wrote: > This patch simplifies the implementation of the scsiback driver > but does not change its behavior. > > Signed-off-by: Bart Van Assche > Cc: Juergen Gross > Cc: Christoph Hellwig

[Xen-devel] [qemu-upstream-4.9-testing baseline test] 109926: tolerable FAIL

"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 109926 qemu-upstream-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/109926/

[Xen-devel] [xen-4.9-testing baseline test] 109925: tolerable FAIL

"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 109925 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/109925/ Failures :-/

[Xen-devel] [PATCH 1/5] xen/vcpu: Simplify xen_vcpu related code

Largely mechanical changes to aid unification of xen_vcpu_restore() logic for PV, PVH and PVHVM. xen_vcpu_setup(): the only change in logic is that clamp_max_cpus() is now handled inside the "if (!xen_have_vcpu_info_placement)" block. xen_vcpu_restore(): code movement from enlighten_pv.c to

[Xen-devel] [PATCH 3/5] xen/pv: Fix OOPS on restore for a PV, !SMP domain

If CONFIG_SMP is disabled, xen_setup_vcpu_info_placement() is called from xen_setup_shared_info(). This is fine as far as boot goes, but it means that we also call it in the restore path. This results in an OOPS because we assign to pv_mmu_ops.read_cr2 which is __ro_after_init. Also, though less

[Xen-devel] [PATCH 0/5] xen/pvh*: Support > 32 VCPUs at restore

This patch series fixes a bunch of issues in the xen_vcpu setup logic. Simplify xen_vcpu related code: code refactoring in advance of the rest of the patch series. Support > 32 VCPUs at restore: unify all vcpu restore logic in xen_vcpu_restore() and support > 32 VCPUs for PVH*. Remove vcpu info

[Xen-devel] [PATCH 4/5] xen/vcpu: Handle xen_vcpu_setup() failure in hotplug

The hypercall VCPUOP_register_vcpu_info can fail. This failure is handled by making per_cpu(xen_vcpu, cpu) point to its shared_info slot and those without one (cpu >= MAX_VIRT_CPUS) be NULL. For PVH/PVHVM, this is not enough, because we also need to pull these VCPUs out of circulation. Fix for

[Xen-devel] [PATCH 5/5] xen/vcpu: Handle xen_vcpu_setup() failure at boot

On PVH, PVHVM, at failure in the VCPUOP_register_vcpu_info hypercall we limit the number of cpus to to MAX_VIRT_CPUS. However, if this failure had occurred for a cpu beyond MAX_VIRT_CPUS, we continue to function with > MAX_VIRT_CPUS. This leads to problems at the next save/restore cycle when

[Xen-devel] [PATCH 2/5] xen/pvh*: Support > 32 VCPUs at domain restore

When Xen restores a PVHVM or PVH guest, its shared_info only holds up to 32 CPUs. The hypercall VCPUOP_register_vcpu_info allows us to setup per-page areas for VCPUs. This means we can boot PVH* guests with more than 32 VCPUs. During restore the per-cpu structure is allocated freshly by the

[Xen-devel] [linux-linus test] 109920: regressions - FAIL

flight 109920 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/109920/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 12 guest-saverestore fail REGR. vs. 109656

[Xen-devel] [PATCH v3 12/12] xen/scsifront: Remove code that zeroes driver-private command data

Since the SCSI core zeroes driver-private command data, remove that code from the xen-scsifront driver. Signed-off-by: Bart Van Assche Reviewed-by: Hannes Reinecke Reviewed-by: Juergen Gross Reviewed-by: Christoph Hellwig

Re: [Xen-devel] [PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs

On Fri, 2 Jun 2017, Julien Grall wrote: > Hi Andre, > > On 05/26/2017 06:35 PM, Andre Przywara wrote: > > @@ -441,6 +443,40 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned > > int virtual_irq) > > #endif > > } > > +/* > > + * Find an unused LR to insert an IRQ into, starting with

Re: [Xen-devel] [PATCH v10 26/32] ARM: vITS: handle MOVI command

On Fri, 2 Jun 2017, Julien Grall wrote: > Hi, > > On 05/31/2017 07:49 PM, Julien Grall wrote: > > > I don't want to introduce any more hardcoding, I just would like the > > > existing vgic_migrate_irq to be called. > > > > It is going to need a bit of rework to get it working with LPI as the

Re: [Xen-devel] [PATCH] x86/HVM: correct notion of new CPL in task switch emulation

On 02/06/17 21:02, Andrew Cooper wrote: > On 01/06/17 13:11, Jan Beulich wrote: >> Reported-by: Andrew Cooper >> Signed-off-by: Jan Beulich > I have finally managed to reproduce the original vmentry failure with an > XTF test. FWIW, the vmentry

[Xen-devel] [PATCH v8] ns16550: Add support for UART parameters to be specifed with name-value pairs

Add name=value parsing options for com1 and com2 to add flexibility in setting register values for MMIO UART devices. Maintain backward compatibility with previous positional parameter specfications. eg. com1=115200,8n1,0x3f8,4 eg. com1=115200,8n1,0x3f8,4,reg_width=4,reg_shift=2 eg.

Re: [Xen-devel] [PATCH] x86/HVM: correct notion of new CPL in task switch emulation

On 01/06/17 13:11, Jan Beulich wrote: > Commit aac1df3d03 ("x86/HVM: introduce hvm_get_cpl() and respective > hook") went too far in one aspect: When emulating a task switch we > really shouldn't be looking at what hvm_get_cpl() returns, as we're > switching all segment registers. > > However,

[Xen-devel] [PATCH v3 12/18] xen/pvcalls: implement poll command

Implement poll on passive sockets by requesting a delayed response with mappass->reqcopy, and reply back when there is data on the passive socket. Poll on active socket is unimplemented as by the spec, as the frontend should just wait for events and check the indexes on the indexes page. Only

[Xen-devel] [PATCH v3 03/18] xen/pvcalls: initialize the module and register the xenbus backend

Keep a list of connected frontends. Use a semaphore to protect list accesses. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/pvcalls-back.c | 22

[Xen-devel] [PATCH v3 05/18] xen/pvcalls: connect to a frontend

Introduce a per-frontend data structure named pvcalls_fedata. It contains pointers to the command ring, its event channel, a list of active sockets and a tree of passive sockets (passing sockets need to be looked up from the id on listen, accept and poll commands, while active sockets only on

[Xen-devel] [PATCH v3 08/18] xen/pvcalls: implement connect command

Allocate a socket. Keep track of socket <-> ring mappings with a new data structure, called sock_mapping. Implement the connect command by calling inet_stream_connect, and mapping the new indexes page and data ring. Allocate a workqueue and a work_struct, called ioworker, to perform reads and

[Xen-devel] [PATCH v3 07/18] xen/pvcalls: implement socket command

Just reply with success to the other end for now. Delay the allocation of the actual socket to bind and/or connect. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/pvcalls-back.c | 29 - 1 file

[Xen-devel] [PATCH v3 18/18] xen: introduce a Kconfig option to enable the pvcalls backend

Also add pvcalls-back to the Makefile. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/Kconfig | 12 drivers/xen/Makefile | 1 + 2 files changed, 13 insertions(+) diff --git a/drivers/xen/Kconfig

[Xen-devel] [PATCH v3 15/18] xen/pvcalls: implement the ioworker functions

We have one ioworker per socket. Each ioworker goes through the list of outstanding read/write requests. Once all requests have been dealt with, it returns. We use one atomic counter per socket for "read" operations and one for "write" operations to keep track of the reads/writes to do. We also

[Xen-devel] [PATCH v3 17/18] xen/pvcalls: implement write

When the other end notifies us that there is data to be written (pvcalls_back_conn_event), increment the io and write counters, and schedule the ioworker. Implement the write function called by ioworker by reading the data from the data ring, writing it to the socket by calling inet_sendmsg. Set

[Xen-devel] [PATCH v3 02/18] xen/pvcalls: introduce the pvcalls xenbus backend

Introduce a xenbus backend for the pvcalls protocol, as defined by https://xenbits.xen.org/docs/unstable/misc/pvcalls.html. This patch only adds the stubs, the code will be added by the following patches. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky

[Xen-devel] [PATCH v3 11/18] xen/pvcalls: implement accept command

Implement the accept command by calling inet_accept. To avoid blocking in the kernel, call inet_accept(O_NONBLOCK) from a workqueue, which get scheduled on sk_data_ready (for a passive socket, it means that there are connections to accept). Use the reqcopy field to store the request. Accept the

[Xen-devel] [PATCH v3 04/18] xen/pvcalls: xenbus state handling

Introduce the code to handle xenbus state changes. Implement the probe function for the pvcalls backend. Write the supported versions, max-page-order and function-calls nodes to xenstore, as required by the protocol. Introduce stub functions for disconnecting/connecting to a frontend.

[Xen-devel] [PATCH v3 06/18] xen/pvcalls: handle commands from the frontend

When the other end notifies us that there are commands to be read (pvcalls_back_event), wake up the backend thread to parse the command. The command ring works like most other Xen rings, so use the usual ring macros to read and write to it. The functions implementing the commands are empty stubs

[Xen-devel] [PATCH v3 13/18] xen/pvcalls: implement release command

Release both active and passive sockets. For active sockets, make sure to avoid possible conflicts with the ioworker reading/writing to those sockets concurrently. Set map->release to let the ioworker know atomically that the socket will be released soon, then wait until the ioworker finishes

[Xen-devel] [PATCH v3 01/18] xen: introduce the pvcalls interface header

Introduce the C header file which defines the PV Calls interface. It is imported from xen/include/public/io/pvcalls.h. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- include/xen/interface/io/pvcalls.h |

[Xen-devel] [PATCH v3 09/18] xen/pvcalls: implement bind command

Allocate a socket. Track the allocated passive sockets with a new data structure named sockpass_mapping. It contains an unbound workqueue to schedule delayed work for the accept and poll commands. It also has a reqcopy field to be used to store a copy of a request for delayed work. Reads/writes to

[Xen-devel] [PATCH v3 14/18] xen/pvcalls: disconnect and module_exit

Implement backend_disconnect. Call pvcalls_back_release_active on active sockets and pvcalls_back_release_passive on passive sockets. Implement module_exit by calling backend_disconnect on frontend connections. Signed-off-by: Stefano Stabellini CC:

[Xen-devel] [PATCH v3 16/18] xen/pvcalls: implement read

When an active socket has data available, increment the io and read counters, and schedule the ioworker. Implement the read function by reading from the socket, writing the data to the data ring. Set in_error on error. Signed-off-by: Stefano Stabellini CC:

[Xen-devel] [PATCH v3 10/18] xen/pvcalls: implement listen command

Call inet_listen to implement the listen command. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/pvcalls-back.c | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git

[Xen-devel] [PATCH v3 00/18] introduce the Xen PV Calls backend

Hi all, this series introduces the backend for the newly introduced PV Calls procotol. PV Calls is a paravirtualized protocol that allows the implementation of a set of POSIX functions in a different domain. The PV Calls frontend sends POSIX function calls to the backend, which implements them

Re: [Xen-devel] [PATCH v2 11/18] xen/pvcalls: implement accept command

On Fri, 26 May 2017, Boris Ostrovsky wrote: > > static void __pvcalls_back_accept(struct work_struct *work) > > { > > + struct sockpass_mapping *mappass = container_of( > > + work, struct sockpass_mapping, register_work); > > + struct sock_mapping *map; > > + struct

Re: [Xen-devel] [PATCH v2 07/18] xen/pvcalls: implement socket command

On Fri, 26 May 2017, Boris Ostrovsky wrote: > On 05/19/2017 07:22 PM, Stefano Stabellini wrote: > > Just reply with success to the other end for now. Delay the allocation > > of the actual socket to bind and/or connect. > > > > Signed-off-by: Stefano Stabellini > > CC:

Re: [Xen-devel] [PATCH v2 07/18] xen/pvcalls: implement socket command

On Fri, 26 May 2017, Boris Ostrovsky wrote: > > static int pvcalls_back_socket(struct xenbus_device *dev, > > struct xen_pvcalls_request *req) > > { > > - return 0; > > + struct pvcalls_back_priv *priv; > > + int ret; > > + struct xen_pvcalls_response *rsp; > > + > > + priv

Re: [Xen-devel] [PATCH v2 06/18] xen/pvcalls: handle commands from the frontend

On Fri, 26 May 2017, Boris Ostrovsky wrote: > On 05/19/2017 07:22 PM, Stefano Stabellini wrote: > > + > > static void pvcalls_back_work(struct work_struct *work) > > { > > + struct pvcalls_back_priv *priv = container_of(work, > > + struct pvcalls_back_priv, register_work); > > +

[Xen-devel] [libvirt test] 109918: trouble: blocked/broken/pass

flight 109918 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/109918/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 3 host-install(3)broken REGR. vs. 109793

Re: [Xen-devel] [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority

On 05/31/2017 11:42 AM, Julien Grall wrote: Hi Stefano, On 30/05/17 22:39, Stefano Stabellini wrote: On Tue, 30 May 2017, Julien Grall wrote: Hi Andre, On 26/05/17 18:35, Andre Przywara wrote: When reading the priority value of a virtual interrupt, we were taking the respective rank lock

Re: [Xen-devel] [PATCH v10 32/32] ARM: vITS: create ITS subnodes for Dom0 DT

Hi Andre, On 05/26/2017 06:35 PM, Andre Przywara wrote: 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

Re: [Xen-devel] [PATCH v10 31/32] ARM: vITS: create and initialize virtual ITSes for Dom0

Hi Andre, On 05/26/2017 06:35 PM, Andre Przywara wrote: For each hardware ITS create and initialize a virtual ITS for Dom0. We use the same memory mapped address to keep the doorbell working. This introduces a function to initialize a virtual ITS. We maintain a list of virtual ITSes, at the

Re: [Xen-devel] [PATCH v10 29/32] ARM: vITS: handle INVALL command

Hi Andre, On 05/26/2017 06:35 PM, Andre Przywara wrote: +do +{ +nr_lpis = radix_tree_gang_lookup(>d->arch.vgic.pend_lpi_tree, + (void **)pirqs, vlpi, + ARRAY_SIZE(pirqs)); + +for ( i = 0; i <

Re: [Xen-devel] [PATCH v9 25/28] ARM: vITS: handle INVALL command

And I obviously commented on the wrong version :/.I will replicate the command on v10. Sorry for the inconvenience. On 06/02/2017 06:24 PM, Julien Grall wrote: Hi Andre, On 05/11/2017 06:53 PM, Andre Przywara wrote: +do +{ +nr_lpis =

Re: [Xen-devel] [PATCH v9 25/28] ARM: vITS: handle INVALL command

Hi Andre, On 05/11/2017 06:53 PM, Andre Przywara wrote: +do +{ +nr_lpis = radix_tree_gang_lookup(>d->arch.vgic.pend_lpi_tree, + (void **)pirqs, vlpi, + ARRAY_SIZE(pirqs)); + +for ( i = 0; i <

Re: [Xen-devel] [PATCH v10 27/32] ARM: vITS: handle DISCARD command

Hi Andre, On 05/26/2017 06:35 PM, Andre Przywara wrote: 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

Re: [Xen-devel] [PATCH v10 26/32] ARM: vITS: handle MOVI command

Hi, On 05/31/2017 07:49 PM, Julien Grall wrote: I don't want to introduce any more hardcoding, I just would like the existing vgic_migrate_irq to be called. It is going to need a bit of rework to get it working with LPI as the code is currently gated with (p->desc). For what benefits? Not

Re: [Xen-devel] [PATCH v10 25/32] ARM: vITS: handle MAPTI/MAPI command

Hi Andre, On 05/26/2017 06:35 PM, Andre Przywara wrote: The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU pair and actually instantiates LPI interrupts. MAPI is just a variant of this comment, where the LPI ID is the same as the event ID. We connect the already allocated host

[Xen-devel] [PATCH for-4.9] x86/boot: Fix the boot time relocation calculations

c/s b28044226e1 "x86: make Xen early boot code relocatable" introduces mov $sym_offs(__image_base__),%esi to the legacy boot path. However, this is by definition 0, which means the boot code only functions correctly when Xen is loaded at its preferred physical address (2M at the time of

Re: [Xen-devel] [PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs

Hi Andre, On 05/26/2017 06:35 PM, Andre Przywara wrote: @@ -441,6 +443,40 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq) #endif } +/* + * Find an unused LR to insert an IRQ into, starting with the LR given + * by @lr. If this new interrupt is a PRISTINE LPI,

Re: [Xen-devel] [PATCH v10 23/32] ARM: vITS: handle MAPD command

Hi Andre, On 05/26/2017 06:35 PM, Andre Przywara wrote: diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h index d162e89..e78dadf 100644 --- a/xen/include/asm-arm/gic_v3_its.h +++ b/xen/include/asm-arm/gic_v3_its.h @@ -173,6 +173,11 @@ struct pending_irq

Re: [Xen-devel] [PATCH v10 19/32] ARM: vITS: provide access to struct pending_irq

On 06/02/2017 05:32 PM, Julien Grall wrote: /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */ void gicv3_its_dt_init(const struct dt_device_node *node) { diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h index

Re: [Xen-devel] [RFC PATCH v4] xen: credit2: provide custom option to create runqueue

Hi, Can you please provide comments on the shared patch. Thanks in advance. Regards, ~Praveen. On Wed, 2017-04-19 at 23:15 +0530, Praveen Kumar wrote: > The patch introduces a new, very flexible way of arranging runqueues > in Credit2. > It allows to specify, explicitly and precisely, what

Re: [Xen-devel] [PATCH v10 22/32] ARM: vITS: handle CLEAR command

Hi Andre, On 05/26/2017 06:35 PM, Andre Przywara wrote: 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. As read_itte() is now eventually used, we add the static keyword.

Re: [Xen-devel] [PATCH v10 20/32] ARM: vITS: handle INT command

Hi Andre, On 05/26/2017 06:35 PM, Andre Przywara wrote: 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-v3-its.c | 21 + 1

Re: [Xen-devel] [Xen-devel[PATCH Resend v2] xen: common: rbtree: ported updates from linux tree

On Thu, 2017-06-01 at 09:43 +0200, Dario Faggioli wrote: > On Thu, 2017-06-01 at 01:26 -0600, Jan Beulich wrote: > > > > > > > > > > > > > > > > > > > On 31.05.17 at 23:20, wrote: > > > I have not imported augmented and rcu rbtree functionality to the > > > xen tree,

[Xen-devel] [PATCH v3.1 8/8] osstest: hook FreeBSD flight into cr-daily-branch

Add the missing pieces so that cr-daily-branch knows how to create a FreeBSD flight. This has been tested by calling `./cr-daily-branch freebsd`. Note that there are two missing pieces. The first one is correctly setting the FREEBSD_BUILDJOB environment variable when calling make-freebsd-flight,

Re: [Xen-devel] [PATCH v10 19/32] ARM: vITS: provide access to struct pending_irq

Hi Andre, On 05/26/2017 06:35 PM, Andre Przywara wrote: For each device we allocate one struct pending_irq for each virtual event (MSI). Provide a helper function which returns the pointer to the appropriate struct, to be able to find the right struct when given a virtual deviceID/eventID pair.

[Xen-devel] [linux-4.9 test] 109913: regressions - FAIL

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

Re: [Xen-devel] [Xen-devel[PATCH Resend v2] xen: common: rbtree: ported updates from linux tree

On Thu, 2017-06-01 at 01:26 -0600, Jan Beulich wrote: > > > > > > > > > > > > > On 31.05.17 at 23:20, wrote: > > The patch imports the changes and updates of the rbtree > > implementaiton > > from Linux tree. But since, the only current implementation is with > >

Re: [Xen-devel] [Resend][PATCH 01/17] rb_tree: reorganize code in rb_erase() for additional changes

On Thu, 2017-06-01 at 10:01 +0200, Dario Faggioli wrote: > On Wed, 2017-05-31 at 23:56 +0100, Andrew Cooper wrote: > > > > As an example, see > > > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=b01c2fb5834 > > ae > > a0328db55c310caa34173021d3d > > > Nice, I especially like how the

Re: [Xen-devel] [PATCH v10 18/32] ARM: vITS: introduce translation table walks

Hi Andre, On 05/26/2017 06:35 PM, Andre Przywara wrote: The ITS stores the target (v)CPU and the (virtual) LPI number in tables. Introduce functions to walk those tables and translate an device ID - event ID pair into a pair of virtual LPI and vCPU. We map those tables on demand - which is

Re: [Xen-devel] [PATCH] xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU

> > static int set_affinity_irq(struct irq_data *data, const struct cpumask > *dest, > bool force) > diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c > index 10f1ef5..1192f24 100644 > --- a/drivers/xen/evtchn.c > +++ b/drivers/xen/evtchn.c > @@ -58,6 +58,8 @@

[Xen-devel] Xen 4.9: Release date

Hi all, There are some pending security issues that have been found during the hardening period, which haven't been pre-disclosed yet. I am going to delay the release until one week after the embargo has lifted. I will give an exact time frame when they have been pre-disclosed. Cheers, --

Re: [Xen-devel] [PATCH v2 0/3] libxl: add PV display device driver interface

On Thu, May 25, 2017 at 3:17 PM, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > These patches add PV display device to libxl and xl. > > Changes since v1: > * add connector id; > * set connector resolution and id to Xen store; > > Oleksandr

Re: [Xen-devel] [PATCH 1/8] arm/mem_access: Add (TCR_|TTBCR_)* defines

I have two series on my inbox with the same patches. I assume it is a mistake and only reviewed the "RFC PATCH v2" version. Let me know if it is not right. Cheers, On 06/01/2017 04:18 PM, Sergej Proskurin wrote: This commit adds (TCR_|TTBCR_)* defines to simplify access to the respective

Re: [Xen-devel] [RFC PATCH v2 7/8] arm/mem_access: Add short-descriptor based gpt

Hi Sergej, On 06/01/2017 04:18 PM, Sergej Proskurin wrote: This commit adds functionality to walk the guest's page tables using the short-descriptor translation table format for both ARMv7 and ARMv8. The implementation is based on ARM DDI 0487A-g G4-4189 and ARM DDI 0406C-b B3-1506.

Re: [Xen-devel] [PATCH] xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU

On 02/06/17 16:49, Anoob Soman wrote: > A HVM domian booting generates around 200K (evtchn:qemu-dm xen-dyn) > interrupts,in a short period of time. All these evtchn:qemu-dm are bound > to VCPU 0, until irqbalance sees these IRQ and moves it to a different VCPU. > In one configuration, irqbalance

Re: [Xen-devel] Check for irqs_disabled in evtchn_fifo_unmask

On 01/06/17 19:01, Anoob Soman wrote: > Hi, > > Can someone explain, why evtchn_fifo_unmask() requires irqs_disabled(). > What happens, if irqs are not disabled ? evtchn_fifo_unmask() seems to be not critical, but evtchn_2l_unmask() might be racy if another event is coming in in the middle. The

[Xen-devel] [PATCH] xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU

A HVM domian booting generates around 200K (evtchn:qemu-dm xen-dyn) interrupts,in a short period of time. All these evtchn:qemu-dm are bound to VCPU 0, until irqbalance sees these IRQ and moves it to a different VCPU. In one configuration, irqbalance runs every 10 seconds, which means irqbalance

[Xen-devel] [PATCH v4.1 3/4] x86/pt: enable binding of GSIs to a PVH Dom0

Achieve this by expanding pt_irq_create_bind in order to support mapping interrupts of type PT_IRQ_TYPE_PCI to a PVH Dom0. GSIs bound to Dom0 are always identity bound, which means the all the fields inside of the u.pci sub-struct are ignored, and only the machine_irq is actually used in order to

[Xen-devel] [PATCH v3 4/8] osstest: add a FreeBSD host install recipe

The installation is performed using the bsdinstall tool, which is part of the FreeBSD base system. The installer image is setup with the osstest ssh keys and sshd enabled by default, which allows the test harness to just ssh into the box, create the install config file and launch the scripted

[Xen-devel] [PATCH v3 1/8] osstest: make built_stash_file store a path_ runvar for each file

And introduce built_stash_debugfile in order the keep the previous behavior of built_stash_file. Signed-off-by: Roger Pau Monné Acked-by: Ian Jackson --- Osstest/TestSupport.pm | 14 -- ts-kernel-build| 4 ++-- ts-xen-build

[Xen-devel] [PATCH v3 2/8] osstest: move known_hosts generation to TestSupport

This is equivalent to the already existing authorized_keys function, and generates the contents of the known_hosts file that should be installed on targets. Signed-off-by: Roger Pau Monné Acked-by: Ian Jackson --- Osstest/Debian.pm | 36

[Xen-devel] [PATCH v3 8/8] osstest: hook FreeBSD flight into cr-daily-branch

Add the missing pieces so that cr-daily-branch knows how to create a FreeBSD flight. This has been tested by calling `./cr-daily-branch freebsd`. Note that there are two missing pieces. The first one is correctly setting the FREEBSD_BUILDJOB environment variable when calling make-freebsd-flight,

[Xen-devel] [PATCH v3 5/8] osstest: introduce a FreeBSD build script

In order to generate the FreeBSD installer image and the install media. The install sets are the vanilla ones generated by the 'ftp' release target. The installer image is handcrafted based on the filesystem created by the 'bootonly' target, which is then populated with the ssh host keys, and

[Xen-devel] [PATCH v3 0/8] osstest: initial FreeBSD support

Hello, This series introduces initial FreeBSD host support to osstest. The current series allow installing a bare-metal host with FreeBSD and building FreeBSD on it in order to generate new install media that can be fed into the installer script. This is still very limited, since no Xen testing

[Xen-devel] [PATCH v3 3/8] osstest: introduce helper to get per-host tftp prefix

This is used in order to get the per-host tftp prefix, used to store the host initrd file. Signed-off-by: Roger Pau Monné --- Changes since v1: - New in this version. --- Osstest/TestSupport.pm | 8 +++- ts-host-install| 2 +- 2 files changed, 8 insertions(+),

[Xen-devel] [PATCH v3 7/8] osstest: introduce a script to create a FreeBSD flight

This requires changes in several places in order to accommodate the FreeBSD build, which although it's a build job, it doesn't have the same set of dependencies as the current builds. First, a new build recipe is added to sg-run-job, and accordingly sg-run-job is also made aware about the

[Xen-devel] [PATCH v3 6/8] osstest: introduce a script to set the hostflags for FreeBSD jobs

Due to the nature of the FreeBSD install media, which is self-generated from the ts-freebsd-build script, the hostflags set to FreeBSD jobs are related to the current version under test. The following hostflags might need to be fetched from the runvars of a previous build-$arch-freebsd job: -

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

This run is configured for baseline tests only. flight 71481 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71481/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-libvirt 5 libvirt-build

[Xen-devel] [xen-unstable-smoke test] 109935: tolerable trouble: broken/pass - PUSHED

flight 109935 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/109935/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12

[Xen-devel] [linux-4.1 test] 109910: regressions - trouble: blocked/broken/fail/pass

flight 109910 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/109910/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 106776

Re: [Xen-devel] [RFC PATCH v2 6/8] arm/mem_access: Add long-descriptor based gpt

Hi Sergej, On 06/01/2017 04:18 PM, Sergej Proskurin wrote: This commit adds functionality to walk the guest's page tables using the long-descriptor translation table format for both ARMv7 and ARMv8. Similar to the hardware architecture, the implementation supports different page granularities

Re: [Xen-devel] [PATCH v4 3/4] x86/pt: enable binding of GSIs to a PVH Dom0

On 06/02/2017 04:41 AM, Roger Pau Monne wrote: > On Thu, Jun 01, 2017 at 06:13:22PM -0400, Boris Ostrovsky wrote: >>> @@ -696,7 +777,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq) >>> struct hvm_irq_dpci *dpci = domain_get_irq_dpci(d); >>> struct hvm_pirq_dpci *pirq_dpci =

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

This run is configured for baseline tests only. flight 71480 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71480/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-libvirt 5 libvirt-build

Re: [Xen-devel] (pv)?grub and PVHv2

On Fri, Jun 02, 2017 at 12:16:06PM +0100, Anthony PERARD wrote: > On Fri, Jun 02, 2017 at 10:58:54AM +0100, Roger Pau Monné wrote: > > On Fri, Jun 02, 2017 at 11:33:50AM +0200, Marek Marczykowski-Górecki wrote: > > > Hi, > > > > > > Is there any method to boot PVHv2 domain using a kernel fetched

Re: [Xen-devel] (pv)?grub and PVHv2

On Fri, Jun 02, 2017 at 10:58:54AM +0100, Roger Pau Monné wrote: > On Fri, Jun 02, 2017 at 11:33:50AM +0200, Marek Marczykowski-Górecki wrote: > > Hi, > > > > Is there any method to boot PVHv2 domain using a kernel fetched from > > that domain's disk image, _without_ mounting it in dom0?

Re: [Xen-devel] [PATCH for-next v3 06/22] x86/traps: move PV hypercall handlers to pv/traps.c

On Wed, May 31, 2017 at 05:45:14AM -0600, Jan Beulich wrote: > >>> On 31.05.17 at 13:14, wrote: > > On Tue, May 30, 2017 at 11:59:31PM -0600, Jan Beulich wrote: > >> >>> On 30.05.17 at 19:40, wrote: > >> > On 29/05/17 16:40, Jan Beulich wrote: > >>

[Xen-devel] PCI passthrough of USB controllers on Xen 4.8.1, Linux 4.9.29, stubdomain

Hi, I'm trying to passthrough USB controllers (details below) to a HVM domain with qemu running in stubdomain. There are two of them (EHCI and xHCI), neither of them works. The stubdomain is non-standard Linux based with Qemu 2.8.0. Both dom0 and guest are running Linux 4.9.29 very close to

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

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

Re: [Xen-devel] [PATCH v7] ns16550: Add support for UART parameters to be specifed with name-value pairs

On 02/06/17 00:54, Paratey, Swapnil wrote: > >>> Should I submit a v8 with the "CONFIG_HAS_PCI" macro specifications for >>> the case statements? I apologize for not trying the build for ARM >>> beforehand. >> Yes please. >> >> ~Andrew > > Should the contents of "enum serial_param_type" and >

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

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

Re: [Xen-devel] (pv)?grub and PVHv2

On Fri, Jun 02, 2017 at 11:33:50AM +0200, Marek Marczykowski-Górecki wrote: > Hi, > > Is there any method to boot PVHv2 domain using a kernel fetched from > that domain's disk image, _without_ mounting it in dom0? Something like > pvgrub was for PV. Hello, Anthony (Cced) is working on an OVMF

[Xen-devel] (pv)?grub and PVHv2

Hi, Is there any method to boot PVHv2 domain using a kernel fetched from that domain's disk image, _without_ mounting it in dom0? Something like pvgrub was for PV. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read

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

This run is configured for baseline tests only. flight 71477 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71477/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-libvirt 5 libvirt-build

  1   2   >