Re: [Xen-devel] [PATCH v5 09/10] vring: Use the DMA API on Xen

On Sun, Jan 31, 2016 at 10:09:07PM +0200, Michael S. Tsirkin wrote: > On Fri, Jan 29, 2016 at 10:34:59AM +, David Vrabel wrote: > > On 29/01/16 02:31, Andy Lutomirski wrote: > > > Signed-off-by: Andy Lutomirski > > > --- > > > drivers/virtio/virtio_ring.c | 12 >

Re: [Xen-devel] [PATCH v5 00/10] virtio DMA API, yet again

On Mon, Feb 01, 2016 at 10:04:07AM -0800, Andy Lutomirski wrote: > On Mon, Feb 1, 2016 at 3:00 AM, Wei Liu wrote: > > Nice work, Andy. > > > > On Thu, Jan 28, 2016 at 06:31:13PM -0800, Andy Lutomirski wrote: > >> This switches virtio to use the DMA API on Xen and if requested

[Xen-devel] [xen-unstable test] 79622: regressions - FAIL

flight 79622 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/79622/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 5 xen-build fail REGR. vs. 79422 build-i386

Re: [Xen-devel] [PATCH v6 9/9] vring: Use the DMA API on Xen

On Mon, Feb 01, 2016 at 10:00:59AM -0800, Andy Lutomirski wrote: > Signed-off-by: Andy Lutomirski Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] Clarifying PVH mode requirements

On 02/01/2016 11:14 AM, Boris Ostrovsky wrote: Is 'HVMLite' replacing 'PVH'? Or are they separate modes? Yes, HVMlite is replacing PVH. Probably once we get dom0 support. If that's a 'done deal', and it sounds like it is, it'd be useful to have it integrated into:

Re: [Xen-devel] Clarifying PVH mode requirements

On 02/01/2016 10:49 AM, PGNet Dev wrote: On 02/01/2016 06:11 AM, Boris Ostrovsky wrote: This actually never happened for Linux: HVMlite showed up fast enough that it didn't make sense anymore to add 32-bit support to Linux (especially given that AMD was still not supported). Is 'HVMLite'

Re: [Xen-devel] Clarifying PVH mode requirements

On 02/01/2016 11:56 AM, Jan Beulich wrote: On 01.02.16 at 15:54, wrote: This looks very much like it needs backport of 33c19df9a ("x86/PCI: intercept accesses to RO MMIO from dom0s in HVM containers") from unstable, which fixes PVH regression introduced by

[Xen-devel] [linux-3.14 test] 79698: regressions - FAIL

flight 79698 linux-3.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/79698/ 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. 78986

Re: [Xen-devel] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

On Mon, 2016-02-01 at 13:49 +0100, Gerd Hoffmann wrote: > > > Maybe we should define the interface as "guest writes 0xfc to pick > > > address, qemu takes care to place opregion there".  That gives us the > > > freedom to change the qemu implementation (either copy host opregion or > > > map the

Re: [Xen-devel] Clarifying PVH mode requirements

On Mon, Feb 1, 2016 at 11:58 AM, Boris Ostrovsky wrote: > On 02/01/2016 02:27 PM, PGNet Dev wrote: > >> On 02/01/2016 11:14 AM, Boris Ostrovsky wrote: >> >>> Is 'HVMLite' replacing 'PVH'? Or are they separate modes? >>> >>> Yes, HVMlite is replacing PVH.

[Xen-devel] [ovmf test] 79772: regressions - FAIL

flight 79772 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/79772/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 65543

Re: [Xen-devel] [PATCH v3 2/3] libxl: move begin phase job handling

On 01/20/2016 12:00 PM, Joao Martins wrote: > . From libxlMigrationBegin to libxlDomainMigrateBegin3Params(). > This is a preparatory patch to be able to begin a job in the > perform phase. > > Signed-off-by: Joao Martins > --- > src/libxl/libxl_driver.c| 18

[Xen-devel] [linux-next test] 79738: regressions - trouble: blocked/broken/fail/pass

flight 79738 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/79738/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 11 guest-start fail REGR. vs. 79587

Re: [Xen-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Sunday, January 31, 2016 9:42 AM > To: Kay, Allen M; Gerd Hoffmann; David Woodhouse > Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost; > Stefano Stabellini;

[Xen-devel] [linux-3.14 baseline-only test] 38719: regressions - FAIL

This run is configured for baseline tests only. flight 38719 linux-3.14 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38719/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build

Re: [Xen-devel] [PATCH v3 1/3] libxl: add p2p migration

On 01/20/2016 12:00 PM, Joao Martins wrote: > Introduce support for VIR_MIGRATE_PEER2PEER in libvirt migration. > Most of the changes occur at the source and no modifications > at the receiver. > > In P2P mode there is only the Perform phase so we must handle > the connection with the destination

Re: [Xen-devel] [PATCH RFC] Remove PV superpage support (v1).

>>> On 01.02.16 at 09:03, wrote: > On 01/02/16 08:53, Jan Beulich wrote: > On 01.02.16 at 05:54, wrote: >>> On 29/01/16 17:46, Jan Beulich wrote: >>> On 29.01.16 at 17:26, wrote: > On Fri, Jan 29, 2016 at 09:00:15AM -0700,

Re: [Xen-devel] hap_invlpg() vs INVLPGA

On 01/02/16 09:04, Jan Beulich wrote: >>> This, otoh, reads as if you imply we intercept the L2's INVLPG. >>> Yet the INVLPG intercept gets cleared when the domain uses >>> NPT (and your original change also didn't alter any intercept >>> settings). Hence I'm still lost how hap_invlpg() can be

Re: [Xen-devel] hap_invlpg() vs INVLPGA

>>> On 29.01.16 at 18:09, wrote: > On 29/01/16 16:53, Jan Beulich wrote: > On 29.01.16 at 15:02, wrote: >>> On 29/01/16 14:57, Egger, Christoph wrote: On 29/01/16 14:24, Jan Beulich wrote: > Christoph, > > in commit dd6de3ab99

Re: [Xen-devel] [PATCH RFC] Remove PV superpage support (v1).

On 01/02/16 08:53, Jan Beulich wrote: On 01.02.16 at 05:54, wrote: >> On 29/01/16 17:46, Jan Beulich wrote: >> On 29.01.16 at 17:26, wrote: On Fri, Jan 29, 2016 at 09:00:15AM -0700, Jan Beulich wrote: On 29.01.16 at 16:30,

Re: [Xen-devel] hap_invlpg() vs INVLPGA

>>> On 01.02.16 at 09:14, wrote: > On 01/02/16 09:04, Jan Beulich wrote: This, otoh, reads as if you imply we intercept the L2's INVLPG. Yet the INVLPG intercept gets cleared when the domain uses NPT (and your original change also didn't alter any intercept

Re: [Xen-devel] pre Sandy bridge IOMMU support (gm45)

>>> On 30.01.16 at 02:47, wrote: > On Tue, Jan 26, 2016 at 04:37:05AM -0700, Jan Beulich wrote: >> (re-adding xen-devel) >> >> >>> On 26.01.16 at 12:28, wrote: >> > Iommu=0 let the whole Qubes system work, without enforcing hardware >>

[Xen-devel] [PATCH v2 3/4] x86/xstate: fix fault behavior on XRSTORS

XRSTORS unconditionally faults when xcomp_bv has bit 63 clear. Instead of just fixing this issue, overhaul the fault recovery code, which - one of the many mistakes made when xstate support got introduced - was blindly mirroring that accompanying FXRSTOR, neglecting the fact that XRSTOR{,S} aren't

Re: [Xen-devel] [PATCH] MAINTAINERS: cover non-x86 vm_event files

On Sun, 2016-01-31 at 09:30 -0700, Tamas K Lengyel wrote: > > > On Sun, Jan 31, 2016 at 2:07 AM, Razvan Cojocaru om> wrote: > > This patch covers modifications to xen/arch/*/vm_event.c, in order > > to include ARM vm_event maintainership. > > > > Signed-off-by: Razvan

Re: [Xen-devel] Clarifying PVH mode requirements

(Cc Roger) On Sun, Jan 31, 2016 at 01:27:23PM -0800, PGNet Dev wrote: > I run Xen 4.6 Dom0 > > rpm -qa | egrep -i "kernel-default-4|xen-4" > kernel-default-devel-4.4.0-8.1.g9f68b90.x86_64 > xen-4.6.0_08-405.1.x86_64 > > My guests are currently HVM in PVHVM

[Xen-devel] [distros-debian-sid test] 38718: tolerable FAIL

flight 38718 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38718/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-sid-netboot-pvgrub 10 guest-start fail blocked in 38654

Re: [Xen-devel] [COVERITY ACCESS] for Doug Goldstein

On Fri, Jan 29, 2016 at 10:16:04AM -0600, Doug Goldstein wrote: > Hi all, > > I agree to the conditions in the Xen Project Security [1] and Coverity > [2] Contribution guidelines. > > I have been a Gentoo Linux developer since 2001 and involved with > downstream packaging of virtualization

Re: [Xen-devel] [PATCH] xl: don't free additional memory on soft reset

On Thu, Jan 28, 2016 at 11:58:25AM +0100, Vitaly Kuznetsov wrote: > We don't need to free anything extra from Dom0 in order to perform soft > reset. It can also fail soft reset if it happens that we don't have this > memory (which we don't need) available. > > Signed-off-by: Vitaly Kuznetsov

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

On Sat, 2016-01-30 at 14:18 +0100, Tommi Airikka wrote: > > > On Wed, Jan 27, 2016 at 7:30 PM, Konrad Rzeszutek Wilk e.com> wrote: > > On Sat, Jan 23, 2016 at 05:12:04PM +0100, Tommi Airikka wrote: > > > Xen developers, > > > > > > After an upgrade of my Debian Jessie dom0

[Xen-devel] Xen 4.7 Development Update

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

[Xen-devel] [PATCH v6] x86/p2m: use large pages for MMIO mappings

When mapping large BARs (e.g. the frame buffer of a graphics card) the overhead of establishing such mappings using only 4k pages has, particularly after the XSA-125 fix, become unacceptable. Alter the XEN_DOMCTL_memory_mapping semantics once again, so that there's no longer a fixed amount of

Re: [Xen-devel] hap_invlpg() vs INVLPGA

>>> On 01.02.16 at 10:41, wrote: > On 01/02/16 10:00, Jan Beulich wrote: > On 01.02.16 at 09:14, wrote: >>> On 01/02/16 09:04, Jan Beulich wrote: >> This, otoh, reads as if you imply we intercept the L2's INVLPG. >> Yet the INVLPG intercept gets

Re: [Xen-devel] Clarifying PVH mode requirements

El 31/01/16 a les 22.27, PGNet Dev ha escrit: > I run Xen 4.6 Dom0 > > rpm -qa | egrep -i "kernel-default-4|xen-4" > kernel-default-devel-4.4.0-8.1.g9f68b90.x86_64 > xen-4.6.0_08-405.1.x86_64 Are your kernels compiled with CONFIG_PVH enabled? > My guests are currently HVM in

Re: [Xen-devel] [PATCH RFC] xen/libxl/libxl: RIP PV superpage.

You have two "libxl" in subject line. On Fri, Jan 29, 2016 at 10:30:46AM -0500, Konrad Rzeszutek Wilk wrote: > The last bastion of users is moving away from needing > this. > > Please note that there was an partial removal by > c/s 9b3c6b13e0c085ceb53210f8e682a073096b94fa > "libxc: remove

Re: [Xen-devel] [PATCH] x86: shrink 'struct domain', was already PAGE_SIZE

On 2/1/2016 12:47 PM, Jan Beulich wrote: On 01.02.16 at 08:42, wrote: The X86 domain structure already occupied PAGE_SIZE (4096). Looking @ the memory layout of the structure, we could see that overall most was occupied by (used the pahole tool on domain.o): *

Re: [Xen-devel] [linux-3.14 test] 79397: regressions - FAIL

On Sat, 2016-01-30 at 04:19 +, osstest service owner wrote: > flight 79397 linux-3.14 real [real] > http://logs.test-lab.xenproject.org/osstest/logs/79397/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >  

Re: [Xen-devel] [linux-3.10 test] 79465: regressions - FAIL

On Sun, 2016-01-31 at 14:02 +, osstest service owner wrote: > flight 79465 linux-3.10 real [real] > http://logs.test-lab.xenproject.org/osstest/logs/79465/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >  

Re: [Xen-devel] [PATCH RFC] Remove PV superpage support (v1).

On Fri, 2016-01-29 at 10:30 -0500, Konrad Rzeszutek Wilk wrote: >  - Deal with documentation? I removed the allowsuperpage from > documentation >    but perhaps it should just mention deprecated? "deprecated" means "still available but use is discouraged". Since AIUI you really are removing PV

Re: [Xen-devel] [PATCH] x86: Convert shadow-paging to Kconfig

At 18:20 + on 29 Jan (1454091618), Andrew Cooper wrote: > Signed-off-by: Andrew Cooper Acked-by: Tim Deegan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] Clarifying PVH mode requirements

El 01/02/16 a les 4.47, PGNet Dev ha escrit: > In any case, the !st issue, prior to any guest being launched, simply > adding > >> @ GRUBG cfg >> >> -GRUB_CMDLINE_XEN=" ..." >> +GRUB_CMDLINE_XEN=" dom0pvh ..." Does your kernel support PVH mode (ie: CONFIG_PVH enabled?) > causes boot

Re: [Xen-devel] [PATCH] x86: shrink 'struct domain', was already PAGE_SIZE

>>> On 01.02.16 at 08:42, wrote: > The X86 domain structure already occupied PAGE_SIZE (4096). > > Looking @ the memory layout of the structure, we could see that > overall most was occupied by (used the pahole tool on domain.o): > * sizeof(domain.arch) =

Re: [Xen-devel] [PATCH v5 00/10] virtio DMA API, yet again

Nice work, Andy. On Thu, Jan 28, 2016 at 06:31:13PM -0800, Andy Lutomirski wrote: > This switches virtio to use the DMA API on Xen and if requested by > module option. > > This fixes virtio on Xen, and it should break anything because it's > off by default on everything except Xen PV on x86. >

Re: [Xen-devel] [PATCH v2 1/2] altp2m: Merge p2m_set_altp2m_mem_access and p2m_set_mem_access

On Thu, Jan 28, 2016 at 01:58:07PM -0700, Tamas K Lengyel wrote: > The altp2m subsystem in its current form uses its own HVMOP hypercall to set > mem_access permissions, duplicating some of the code already present for > setting regular mem_access permissions. In this patch we consolidate the two

Re: [Xen-devel] hap_invlpg() vs INVLPGA

On 01/02/16 10:00, Jan Beulich wrote: On 01.02.16 at 09:14, wrote: >> On 01/02/16 09:04, Jan Beulich wrote: > This, otoh, reads as if you imply we intercept the L2's INVLPG. > Yet the INVLPG intercept gets cleared when the domain uses > NPT (and your original

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

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

[Xen-devel] [PATCH] x86/hvm: Fix use-after-free introduced by c/s 428607a

c/s 428607a "x86: shrink 'struct domain', was already PAGE_SIZE" introduced a use-after-free error during domain destruction, because of the order in which timers are torn down. (XEN) Xen call trace: (XEN)[] spinlock.c#check_lock+0x1e/0x40 (XEN)[] _spin_lock+0x11/0x52 (XEN)[]

[Xen-devel] [PATCH v8 05/28] xen/arm: ITS: Port ITS driver to Xen

From: Vijaya Kumar K The linux driver is based on 4.1 with below commit id 591e5bec13f15feb13fc445b6c9c59954711c4ac Only following code from Linux ITS driver is ported and compiled - LPI initialization - ITS configuration code - Physical command queue

[Xen-devel] [PATCH v8 01/28] xen/arm: Add bitmap_find_next_zero_area helper function

From: Vijaya Kumar K bitmap_find_next_zero_area helper function will be used by physical ITS driver. This is imported from linux 4.2 Signed-off-by: Vijaya Kumar K Acked-by: Jan Beulich CC: Ian Campbell

[Xen-devel] [PATCH v8 21/28] xen/arm: ITS: Add GICR register emulation

From: Vijaya Kumar K Emulate LPI related changes to GICR registers Signed-off-by: Vijaya Kumar K --- v8: - Updated GICR_PROPBASER and GICR_PENDBASER only on enabling LPIs and added 32/64 bit reg access - Allocated LPI

[Xen-devel] [PATCH v8 23/28] xen/arm: ITS: Allocate pending_lpi descriptors for LPIs

From: Vijaya Kumar K Allocate dynamically pending_lpi descriptors for LPIs Signed-off-by: Vijaya Kumar K --- v8: - Dropped HAS_GICV3 config switch around pending_lpis[] --- xen/arch/arm/vgic-v3-its.c |9 +

[Xen-devel] [PATCH v8 26/28] xen/arm: ITS: Map ITS translation space

From: Vijaya Kumar K ITS translation space contains GITS_TRANSLATER register which is written by device to raise LPI. This space needs to mapped to every domain address space for all physical ITS available,so that device can access GITS_TRANSLATER register using

[Xen-devel] [PATCH v8 06/28] xen/arm: ITS: Add helper functions to manage its_devices

From: Vijaya Kumar K Helper functions to manage its devices using RB-tree are introduced in physical ITS driver. This is global list of all the devices. Signed-off-by: Vijaya Kumar K --- v8: - Added assert on lock in

[Xen-devel] [PATCH v8 18/28] xen/arm: ITS: Export ITS info to Virtual ITS

From: Vijaya Kumar K Export physical ITS information to virtual ITS driver Signed-off-by: Vijaya Kumar K --- v8: - eventID_bits and devID_bits are made its node specific. Max of all the nodes is considered - Moved

[Xen-devel] [PATCH v8 02/28] xen: Add log2 functionality

From: Vijaya Kumar K log2 helper apis are ported from linux from commit 13c07b0286d340275f2d97adf085cecda37ede37 (linux/log2.h: Fix rounddown_pow_of_two(1)) Changes made for xen are: - Only required functionality is retained - Replace fls_long with flsl

[Xen-devel] [PATCH v8 22/28] xen/arm: ITS: Allocate irq descriptors for LPIs

From: Vijaya Kumar K Allocate dynamically irq descriptors for LPIs Signed-off-by: Vijaya Kumar K --- v8: - Use gic_nr_irq_ids() instead of nr_lpis v6: - Add separate patch for irq_pending structures - renamed and moved

[Xen-devel] [PATCH v8 03/28] xen/arm: Set nr_cpu_ids to available number of cpus

From: Vijaya Kumar K nr_cpu_ids for arm platforms is incorrectly set to NR_CPUS irrespective of the number of cpus supported by platform. Signed-off-by: Vijaya Kumar K Reviewed-by: Julien Grall --- v6:

[Xen-devel] [PATCH v8 24/28] xen/arm: ITS: Route LPIs

From: Vijaya Kumar K Allocate and initialize irq descriptor for LPIs and route LPIs to guest For LPIs deactivation is not required. Hence GICH_LR.HW is not required to set. Signed-off-by: Vijaya Kumar K --- v7: - Subtract 8192

[Xen-devel] [PATCH v8 20/28] xen/arm: ITS: Add virtual ITS availability check helper

From: Vijaya Kumar K Introduce vgic_is_lpi_supported() helper function to know virtual ITS availability for a domain Signed-off-by: Vijaya Kumar K --- v8: - Dropped its_enabled field v7: - its_enabled field is added to vgic

[Xen-devel] [PATCH v8 04/28] xen/arm: Rename NR_IRQs and vgic_num_irqs helper function

From: Vijaya Kumar K NR_IRQS represents the number of lines (i.e SGIs, PPIs and SPIs). With the introduction of LPIs, NR_IRQs is renamed to NR_ITLINES. Similarly vgic_num_irqs() is renamed as vgic_num_irq_lines(). Signed-off-by: Vijaya Kumar K

[Xen-devel] [PATCH v8 09/28] xen/arm: ITS: Introduce gic_is_lpi helper function

From: Vijaya Kumar K Helper function gic_is_lpi() is used to find if irq is lpi or not. For GICv2 platforms this function returns number of irq ids which represents only number of line irqs. For GICv3 platform irq ids are calculated from nr_lpis if HW supports

[Xen-devel] [PATCH v8 10/28] xen/arm: ITS: Implement hw_irq_controller for LPIs

From: Vijaya Kumar K Implement hw_irq_controller callbacks required to handle LPIs. Signed-off-by: Vijaya Kumar K Reviewed-by: Julien Grall --- v8: - Removed const before hw_irq_controller for lpis v7:

[Xen-devel] [PATCH v8 08/28] xen/arm: ITS: Add APIs to add and assign device

From: Vijaya Kumar K Add APIs to add devices to RB-tree, assign and remove devices to domain. Signed-off-by: Vijaya Kumar K --- v8: - Merged its_free_msi_descs() with its_discard_lpis - Dropped extra spin_unlock() in

[Xen-devel] [PATCH v8 27/28] xen/arm: ITS: Generate ITS node for Dom0

From: Vijaya Kumar K Parse host dt and generate ITS node for Dom0. ITS node resides inside GIC node so when GIC node is encountered look for ITS node. Signed-off-by: Vijaya Kumar K --- v7: - Check on return value v6: -

[Xen-devel] [PATCH v8 28/28] xen/arm: ITS: Add pci devices in ThunderX

From: Vijaya Kumar K ITS initialization required for all PCI devices in ThunderX platform are done by calling from specific mapping function. This patch can be reverted once XEN PCI passthrough framework for arm64 is in available. For now all the PCI devices

[Xen-devel] [PATCH v8 07/28] xen/arm: ITS: Introduce msi_desc for LPIs

From: Vijaya Kumar K Define msi_desc structure for arm and introduce helper functions to access msi_desc member variables. Signed-off-by: Vijaya Kumar K Reviewed-by: Julien Grall ---

[Xen-devel] [PATCH v8 14/28] xen/arm: ITS: Initialize physical ITS and export lpi support

From: Vijaya Kumar K Initialize physical ITS if HW supports LPIs. Signed-off-by: Vijaya Kumar K --- v8: - Rename lpi_support to its_support. - Removed its command line parameter. - Dropped its_enabled global variable.

[Xen-devel] [PATCH v8 12/28] xen/arm: ITS: Plumb hw_irq_controller for LPIs

From: Vijaya Kumar K Change callbacks gic_host_irq_type and gic_guest_irq_type to gic_get_host_irq_type and gic_get_guest_irq_type in gic_hw_operations, which returns hw_irq_controller based on irq type (SPI or LPI). Signed-off-by: Vijaya Kumar K

[Xen-devel] [PATCH v8 00/28] Add ITS support

From: Vijaya Kumar K This is based on DraftG version http://xenbits.xen.org/people/ianc/vits/draftG.pdf Following major features are supported - GICv3 ITS support for arm64 platform - Only Dom0 is supported. For DomU pci passthrough feature is required.

[Xen-devel] [PATCH v8 17/28] xen/arm: ITS: Add GITS registers emulation

From: Vijaya Kumar K Emulate GITS* registers Signed-off-by: Vijaya Kumar K --- v8: - Fixed GITS_BASER0 value. - Added comments for GITS_BASER0. - Support 32/64 bit access for GITS_BASER0 and GITS_CBASER. -

[Xen-devel] [PATCH v8 11/28] xen/arm: ITS: Enable compilation of physical ITS driver

From: Vijaya Kumar K Enable compilation of pITS driver. Signed-off-by: Vijaya Kumar K --- xen/arch/arm/Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index

[Xen-devel] [PATCH v8 16/28] xen/arm: ITS: Add virtual ITS commands support

From: Vijaya Kumar K Add Virtual ITS command processing support to Virtual ITS driver Signed-off-by: Vijaya Kumar K Reviewed-by: Julien Grall --- v8: - Fixed coding styles v7: - Moved

[Xen-devel] [PATCH v8 25/28] xen/arm: ITS: Add domain specific ITS initialization

From: Vijaya Kumar K Call domain specific ITS initialization and introduce callback in vgic for domain free Signed-off-by: Vijaya Kumar K --- v7: - Deprecate use of gic_lpi_supported and instead use vgic_v3_hw.lpi_support

[Xen-devel] [PATCH v8 15/28] xen/arm: ITS: Add virtual ITS driver

From: Vijaya Kumar K This patch introduces virtual ITS driver with following functionality - Introduces helper functions to manage device table and ITT table in guest memory - Helper function to handle virtual ITS devices assigned to domain

[Xen-devel] [PATCH v8 19/28] xen/arm: ITS: Store the number of LPIs allocated per domain

From: Vijaya Kumar K Store the number of lpis allocated per domain in vgic structure Signed-off-by: Vijaya Kumar K --- v8: - Updated commit message and added comments - Removed initialization of vgic.nr_lpis to zero v7: -

[Xen-devel] [PATCH v8 13/28] xen/arm: Correct GICD_TYPER register definition typos

From: Vijaya Kumar K GICD_TYPER register definitions are defined as GICD_TYPE. Rename all GICD_TYPE_* as GICD_TYPER_* Signed-off-by: Vijaya Kumar K --- xen/arch/arm/gic-hip04.c |4 ++-- xen/arch/arm/gic-v2.c

Re: [Xen-devel] [PATCH] Xen/PCI: correct notifier used for device removal

>>> On 01.02.16 at 14:03, wrote: > On 01/02/16 12:16, Jan Beulich wrote: > On 01.02.16 at 13:01, wrote: >>> On 01/02/16 11:58, Jan Beulich wrote: Commit 599bad38cf added BUS_NOTIFY_REMOVED_DEVICE in order to allow avoiding removal

Re: [Xen-devel] [PATCH v5 04/10] vring: Introduce vring_use_dma_api()

On Mon, Feb 01, 2016 at 11:22:03AM +, David Woodhouse wrote: > On Thu, 2016-01-28 at 18:31 -0800, Andy Lutomirski wrote: > > This is a kludge, but no one has come up with a a better idea yet. > > We'll introduce DMA API support guarded by vring_use_dma_api(). > > Eventually we may be able to

Re: [Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2

Ping? (I'd really like to get this resolved, so we don't need to indefinitely run with non-upstream behavior in our distros.) Thanks, Jan >>> On 13.01.16 at 17:15, wrote: On 13.01.16 at 17:00, wrote: >> On 13/01/16 15:36, Jan Beulich wrote:

Re: [Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2

On 01/02/16 13:20, Jan Beulich wrote: > Ping? (I'd really like to get this resolved, so we don't need to > indefinitely run with non-upstream behavior in our distros.) > > Thanks, Jan My remaining issue is whether this loop gets executed by default. I realise that there is a difference between

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

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

Re: [Xen-devel] Clarifying PVH mode requirements

On 02/01/2016 05:28 AM, Roger Pau Monné wrote: IIRC Boris (CCed) added support for 32bit PVH to Linux, so you should be able to use either 32 or 64 kernels. Roger. This actually never happened for Linux: HVMlite showed up fast enough that it didn't make sense anymore to add 32-bit support to

Re: [Xen-devel] [PATCH 2/3] libxl/remus: Move the assert before the info is used. [and 1 more messages]

Wei Liu writes ("Re: [PATCH 3/4] libxl/remus: Change the assert for info to an return"): > On Tue, Jan 26, 2016 at 04:30:59PM -0500, Konrad Rzeszutek Wilk wrote: > > The assert(info) is after quite a lot of manipulations > > on 'info' - which makes the assert pointless because if > > info was

Re: [Xen-devel] [PATCH] Xen/PCI: correct notifier used for device removal

On 01/02/16 12:16, Jan Beulich wrote: On 01.02.16 at 13:01, wrote: >> On 01/02/16 11:58, Jan Beulich wrote: >>> Commit 599bad38cf added BUS_NOTIFY_REMOVED_DEVICE in order to allow >>> avoiding removal of IOMMU mappings before the driver actually got >>> unbound from

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

>>> On 01.02.16 at 13:49, wrote: > On Mon, Feb 01, 2016 at 05:15:16AM -0700, Jan Beulich wrote: >> >>> On 01.02.16 at 13:02, wrote: >> > On Mon, Feb 01, 2016 at 12:52:51AM -0700, Jan Beulich wrote: >> >> >>> On 30.01.16 at 15:38,

Re: [Xen-devel] Clarifying PVH mode requirements

I'll get the dom0pvh issue logs posted. http://xenbits.xen.org/docs/unstable/misc/pvh-readme.txt " ... To boot 64bit dom0 in PVH mode, add dom0pvh to grub xen command line. ..." http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/pvh.markdown no

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

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

Re: [Xen-devel] [PATCH] MAINTAINERS: cover non-x86 vm_event files

> Once vm_event.c is added to ARM: > > I don't think that's a prerequisite for accepting this patch, is it? (In > some ways that's the point -- it covers all future ARCH vm_event.c) > Oh yea, good point. I just found it odd to list files here that don't (yet) exist. Tamas

Re: [Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2

>>> On 01.02.16 at 15:07, wrote: > On 01/02/16 13:20, Jan Beulich wrote: >> Ping? (I'd really like to get this resolved, so we don't need to >> indefinitely run with non-upstream behavior in our distros.) > > My remaining issue is whether this loop gets executed by

Re: [Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2

On 01/02/16 16:28, Jan Beulich wrote: On 01.02.16 at 15:07, wrote: >> On 01/02/16 13:20, Jan Beulich wrote: >>> Ping? (I'd really like to get this resolved, so we don't need to >>> indefinitely run with non-upstream behavior in our distros.) >> My remaining issue

Re: [Xen-devel] [PATCH v2 1/2] altp2m: Merge p2m_set_altp2m_mem_access and p2m_set_mem_access

>>> On 01.02.16 at 16:22, wrote: > Ian Campbell writes ("Re: [PATCH v2 1/2] altp2m: Merge > p2m_set_altp2m_mem_access and p2m_set_mem_access"): >> It's unfortunate that we've found ourselves here, but I think rather than >> deprecating the current and adding a new op

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

Yu, Zhang writes ("Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges."): > On 2/2/2016 12:35 AM, Jan Beulich wrote: >> On 01.02.16 at 17:19, wrote: > >> So, we need also validate this param in hvm_allow_set_param, > >> current although

Re: [Xen-devel] [PATCH v5 04/10] vring: Introduce vring_use_dma_api()

On Mon, 2016-02-01 at 07:39 -0800, Andy Lutomirski wrote: > > >> Could we have an arch_vring_eschew_dma_api(dev) function which the > >> affected architectures could provide (as a prelude to fixing it so that > >> the DMA API does the right thing for *itself*)? > > > > I'm fine with this. > > I

[Xen-devel] [PATCHv7 0/1] x86/ept: reduce translation invalidation impact

This series improves the performance of EPT by further reducing the impact of the translation invalidations (ept_sync_domain()). By: a) Deferring invalidations until the p2m write lock is released. Prior to this change a 16 VCPU guest could not be successfully migrated on an (admittedly slow)

[Xen-devel] [PATCHv7] x86/ept: defer the invalidation until the p2m lock is released

Holding the p2m lock while calling ept_sync_domain() is very expensive since it does a on_selected_cpus() call. IPIs on many socket machines can be very slows and on_selected_cpus() is serialized. It is safe to defer the invalidate until the p2m lock is released except for two cases: 1. When

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

On 2/1/2016 11:14 PM, Yu, Zhang wrote: On 2/1/2016 9:07 PM, Jan Beulich wrote: On 01.02.16 at 13:49, wrote: On Mon, Feb 01, 2016 at 05:15:16AM -0700, Jan Beulich wrote: On 01.02.16 at 13:02, wrote: On Mon, Feb 01, 2016 at 12:52:51AM -0700, Jan

Re: [Xen-devel] Clarifying PVH mode requirements

>>> On 01.02.16 at 15:54, wrote: > On 02/01/2016 08:38 AM, PGNet Dev wrote: >> >> Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default >> ...Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default ... >> >> /EndEntire >> /EndEntire >> file path: file

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

On Mon, 2016-02-01 at 15:19 +, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST v1 5/5] 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. > ... > > Note

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

>>> On 01.02.16 at 16:14, wrote: > But I still do not quite understand. :) > If tool stack can guarantee the validity of a parameter, > under which circumstances will hypervisor be threatened? At least in disaggregated environments the hypervisor cannot trust the

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

On 2/2/2016 12:16 AM, Jan Beulich wrote: On 01.02.16 at 16:14, wrote: But I still do not quite understand. :) If tool stack can guarantee the validity of a parameter, under which circumstances will hypervisor be threatened? At least in disaggregated environments

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

On 2/2/2016 12:35 AM, Jan Beulich wrote: On 01.02.16 at 17:19, wrote: After a second thought, I guess one of the security concern is when some APP is trying to trigger the HVMOP_set_param directly with some illegal values. Not sure what "directly" is supposed to

  1   2   3   >