Re: [Xen-devel] [RFC v3 4/4] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

On 12/5/2017 7:17 AM, Julien Grall wrote: > Hello, > > On 05/12/17 03:59, Sameer Goel wrote: >> This driver follows an approach similar to smmu driver. The intent here >> is to reuse as much Linux code as possible. >> - Glue code has been introduced in headers to bridge the API calls. >> -

[Xen-devel] [xen-unstable-smoke test] 117203: trouble: broken/pass

flight 117203 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117203/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm broken Tests which

[Xen-devel] [xen-4.8-testing test] 117144: tolerable FAIL - PUSHED

flight 117144 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117144/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-credit2 16 guest-start/debian.repeatfail like 116653 test-xtf-amd64-amd64-5 49

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

flight 117143 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/117143/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 115643

[Xen-devel] [xen-unstable-smoke test] 117201: trouble: broken/pass

flight 117201 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117201/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm broken Tests which

[Xen-devel] [xen-unstable-smoke test] 117200: trouble: broken/pass

flight 117200 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117200/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm broken Tests which

Re: [Xen-devel] [RFC v3 2/4] xen/linux_compat: Add a Linux compat header

On 15/12/2017 22:32, Goel, Sameer wrote: On 12/5/2017 5:31 AM, Julien Grall wrote: Hi Sameer, On 05/12/17 03:59, Sameer Goel wrote: For porting files from Linux it is useful to have a Linux API to Xen API mapping header at a common location. This file adds common API functions and other

Re: [Xen-devel] [RFC v3 2/4] xen/linux_compat: Add a Linux compat header

On 12/5/2017 5:31 AM, Julien Grall wrote: > Hi Sameer, > > On 05/12/17 03:59, Sameer Goel wrote: >> For porting files from Linux it is useful to have a Linux API to Xen API >> mapping header at a common location. >> This file adds common API functions and other defines that are needed for >>

[Xen-devel] [qemu-mainline baseline-only test] 72853: trouble: blocked/broken

This run is configured for baseline tests only. flight 72853 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72853/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64

[Xen-devel] [xen-unstable-smoke test] 117193: trouble: broken/pass

flight 117193 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117193/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm broken Tests which

Re: [Xen-devel] [PATCH V3 1/2] Drivers/PCI: Export pcie_has_flr() interface

Thanks Bjorn for your response. Please see below for my comments. So, we should consider one of these options. - set PCI_DEV_FLAGS_NO_FLR_RESET if it is not supported. - pcie_flr() should return if it is not supported If we modify pcie_flr() to return error codes, then we need to modify all

Re: [Xen-devel] [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset with 'reset' SysFS attribute

Jan, One quick update on pcie_flr() specific implementation. Please see below. +static int pcistub_device_reset(struct pci_dev *dev) +{ + struct xen_pcibk_dev_data *dev_data; + bool slot = false, bus = false; + struct pcistub_args arg = {}; + + if (!dev) +

[Xen-devel] [xen-4.7-testing test] 117141: regressions - FAIL

flight 117141 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117141/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-1 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 116665 Tests which

[Xen-devel] [xen-unstable-smoke test] 117187: trouble: broken/pass

flight 117187 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117187/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm broken Tests which

Re: [Xen-devel] [PATCH V3 1/2] Drivers/PCI: Export pcie_has_flr() interface

[+cc Russell, Sinan, Herbert, Srikanth, Derek, Satanand, Felix, Raghu] On Fri, Dec 15, 2017 at 09:48:02AM -0600, Govinda Tatti wrote: > On 12/13/2017 3:24 PM, Bjorn Helgaas wrote: > >On Wed, Dec 13, 2017 at 02:46:57PM -0600, Govinda Tatti wrote: > >>-static bool pcie_has_flr(struct pci_dev

Re: [Xen-devel] [RFC PATCH v3 2/2] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 15/12/2017 16:55, Juergen Gross wrote: > I'm fine with the general idea. > > I'm wondering whether you really want to require CONFIG_XEN for the > KVM case, though. > > Wouldn't it be better to rename arch/x86/xen/enlighten_pvh.c to > arch/x86/pvh.c and arch/x86/xen/xen-pvh.S to

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

flight 117138 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/117138/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116904 test-armhf-armhf-libvirt-xsm 14

Re: [Xen-devel] [PATCH] xen/balloon: Mark unallocated host memory as UNUSABLE

On 12/15/2017 11:04 AM, kbuild test robot wrote: > Hi Boris, > > I love your patch! Yet something to improve: > > [auto build test ERROR on xen-tip/linux-next] > [also build test ERROR on v4.15-rc3 next-20171215] > [if your patch is applied to the wrong git tree, please drop

Re: [Xen-devel] [PATCH] xen/balloon: Mark unallocated host memory as UNUSABLE

On 12/15/2017 10:33 AM, Juergen Gross wrote: > On 15/12/17 15:58, Boris Ostrovsky wrote: >> On 12/15/2017 09:47 AM, Juergen Gross wrote: >>> On 15/12/17 15:24, Boris Ostrovsky wrote: >> + >> +hostmem_resource->start = max_addr; >> +hostmem_resource->end = entry->addr +

Re: [Xen-devel] [PATCH] xen/balloon: Mark unallocated host memory as UNUSABLE

Hi Boris, I love your patch! Yet something to improve: [auto build test ERROR on xen-tip/linux-next] [also build test ERROR on v4.15-rc3 next-20171215] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [Xen-devel] [RFC PATCH v3 2/2] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 13/12/17 00:42, Maran Wilson wrote: > For certain applications it is desirable to rapidly boot a KVM virtual > machine. In cases where legacy hardware and software support within the > guest is not needed, Qemu should be able to boot directly into the > uncompressed Linux kernel binary without

[Xen-devel] [xen-unstable-smoke test] 117183: trouble: broken/pass

flight 117183 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117183/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm broken Tests which

Re: [Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install: don't use the new nic naming scheme

On 12/12/17 15:15, Julien Grall wrote: Hi Wei/Ian, Hi, I have tried this series on Arm64 hardware. I am able to boot and install Debian on AMD Seattle (laxton{0,1}). But I don't get network when using Cavium Thunder-X (rochester{0,1}) after reboot. Looking into more details, the

Re: [Xen-devel] [PATCH] xen/balloon: Mark unallocated host memory as UNUSABLE

On 15/12/17 15:58, Boris Ostrovsky wrote: > On 12/15/2017 09:47 AM, Juergen Gross wrote: >> On 15/12/17 15:24, Boris Ostrovsky wrote: > + > + hostmem_resource->start = max_addr; > + hostmem_resource->end = entry->addr + entry->size; > + for (; i < memmap.nr_entries; i++) { > +

[Xen-devel] Xen Performance Results

Hi all, I have a question concerning a 'correct' Xen configuration to measure performance, as I am currently experiencing a quite unexpected behavior. My overall setup comprises a Skylake micro-architecture based system with a Debian Buster and Linux kernel 4.13.16 running on top of Xen v4.8.

Re: [Xen-devel] Xen release cycle revisited

On 14/12/17 14:13, Juergen Gross wrote: > On 14/12/17 13:43, Julien Grall wrote: >> >> >> On 14/12/17 11:38, Juergen Gross wrote: >>> On 14/12/17 12:28, Julien Grall wrote: On 14/12/17 07:56, Juergen Gross wrote: > Hi all, Hi Juergen, I would recommend to CC

Re: [Xen-devel] [PATCH] xen/balloon: Mark unallocated host memory as UNUSABLE

On 15/12/17 15:24, Boris Ostrovsky wrote: > >>> + >>> + hostmem_resource->start = max_addr; >>> + hostmem_resource->end = entry->addr + entry->size; >>> + for (; i < memmap.nr_entries; i++) { >>> + entry = _e820_table->entries[i]; >>> + if (entry->type == E820_TYPE_RAM)

[Xen-devel] [seabios test] 117134: regressions - FAIL

flight 117134 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/117134/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not

[Xen-devel] [xen-unstable-smoke test] 117178: trouble: broken/pass

flight 117178 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117178/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm broken Tests which

Re: [Xen-devel] [PATCH] xen/balloon: Mark unallocated host memory as UNUSABLE

On 12/12/17 23:51, Boris Ostrovsky wrote: > Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum > reservation") left host memory not assigned to dom0 as available for > memory hotplug. > > Unfortunately this also meant that those regions could be used by > others. Specifically,

Re: [Xen-devel] [PATCH v7 for-next 09/12] vpci/bars: add handlers to map the BARs

>>> On 18.10.17 at 13:40, wrote: > --- /dev/null > +++ b/xen/drivers/vpci/header.c > @@ -0,0 +1,518 @@ > +/* > + * Generic functionality for handling accesses to the PCI header from the > + * configuration space. > + * > + * Copyright (C) 2017 Citrix Systems R > + * > + *

[Xen-devel] [linux-3.18 test] 117131: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PULL 0/6] xen-20171214-tag

On 15 December 2017 at 00:27, Stefano Stabellini wrote: > The following changes since commit 0a0dc59d27527b78a195c2d838d28b7b49e5a639: > > Update version for v2.11.0 release (2017-12-13 14:31:09 +) > > are available in the git repository at: > >

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

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

[Xen-devel] [PATCH v16 11/11] tools/libxenctrl: use new xenforeignmemory API to seed grant table

A previous patch added support for priv-mapping guest resources directly (rather than having to foreign-map, which requires P2M modification for HVM guests). This patch makes use of the new API to seed the guest grant table unless the underlying infrastructure (i.e. privcmd) doesn't support it,

[Xen-devel] [PATCH v16 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

This patch allows grant table frames to be mapped using the XENMEM_acquire_resource memory op. NOTE: This patch expands the on-stack mfn_list array in acquire_resource() but it is still small enough to remain on-stack. Signed-off-by: Paul Durrant Reviewed-by: Jan

Re: [Xen-devel] [PATCH v7 for-next 06/12] pci: split code to size BARs from pci_add_device

>>> On 18.10.17 at 13:40, wrote: > +ret = pci_size_mem_bar(sbdf, idx, NULL, >vf_rlen[i], > + PCI_BAR_VF | > + (i == PCI_SRIOV_NUM_BARS - 1) ? > +

Re: [Xen-devel] [PATCH v7 for-next 05/12] x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH Dom0

>>> On 18.10.17 at 13:40, wrote: > So that MMCFG regions not present in the MCFG ACPI table can be added > at run time by the hardware domain. > > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v16 09/11] tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint

By using a static inline stub in private.h for OS where this functionality is not implemented, the various duplicate stubs in the OS-specific source modules can be avoided. Signed-off-by: Paul Durrant Reviewed-by: Roger Pau Monné Acked-by: Wei Liu

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

... XENMEM_resource_ioreq_server This patch adds support for a new resource type that can be mapped using the XENMEM_acquire_resource memory op. If an emulator makes use of this resource type then, instead of mapping gfns, the IOREQ server will allocate pages from the heap. These pages will

[Xen-devel] [PATCH v16 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

Certain memory resources associated with a guest are not necessarily present in the guest P2M. This patch adds the boilerplate for new memory op to allow such a resource to be priv-mapped directly, by either a PV or HVM tools domain. NOTE: Whilst the new op is not intrinsicly specific to the x86

[Xen-devel] [PATCH v16 00/11] x86: guest resource mapping

This series introduces support for direct mapping of guest resources. The resources are: - IOREQ server pages - Grant tables v16: - Fix default ioreq server code and verified with qemu trad v15: - Correct page ownership of ioreq pages v14: - Responded to more comments from Jan. v13: -

[Xen-devel] [PATCH v16 02/11] x86/hvm/ioreq: simplify code and use consistent naming

This patch re-works much of the ioreq server initialization and teardown code: - The hvm_map/unmap_ioreq_gfn() functions are expanded to call through to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called separately by outer functions. - Several functions now test the validity

[Xen-devel] [PATCH v16 03/11] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page

This patch adjusts the ioreq server code to use type-safe gfn_t values where possible. No functional change. Signed-off-by: Paul Durrant Reviewed-by: Roger Pau Monné Reviewed-by: Wei Liu Acked-by: Jan Beulich

[Xen-devel] [PATCH v16 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

A subsequent patch will introduce a new scheme to allow an emulator to map ioreq server pages directly from Xen rather than the guest P2M. This patch lays the groundwork for that change by deferring mapping of gfns until their values are requested by an emulator. To that end, the pad field of the

[Xen-devel] [PATCH v16 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

A subsequent patch will remove the current implicit limitation on creation of ioreq servers which is due to the allocation of gfns for the ioreq structures and buffered ioreq ring. It will therefore be necessary to introduce an explicit limit and, since this limit should be small, it simplifies

[Xen-devel] [PATCH v16 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

...to allow the calling domain to prevent translation of specified l1e value. Despite what the comment in public/xen.h might imply, specifying a command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with the specified value. Instead, mod_l1_entry() tests whether foreign_dom has

[Xen-devel] [libvirt test] 117133: tolerable all pass - PUSHED

flight 117133 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/117133/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 116965 test-armhf-armhf-libvirt 14

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

> -Original Message- > From: Chao Gao [mailto:chao@intel.com] > Sent: 15 December 2017 00:36 > To: Paul Durrant > Cc: Stefano Stabellini ; Wei Liu > ; Andrew Cooper ; Tim > (Xen.org)

Re: [Xen-devel] [PATCH v6 4/4] hw: convert XenInput keyboard to keycodemapdb

On Wed, Dec 13, 2017 at 03:01:51PM +, Anthony PERARD wrote: > On Tue, Dec 12, 2017 at 02:10:44PM +, Daniel P. Berrange wrote: > > Replace the scancode2linux table with an automatically > > generated table. In doing so, the XenFB keyboard > > handler is also converted to the modern

[Xen-devel] [xen-unstable-smoke test] 117175: trouble: broken/pass

flight 117175 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117175/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm broken Tests which

Re: [Xen-devel] [PATCH v15 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

> -Original Message- > From: Chao Gao [mailto:chao@intel.com] > Sent: 15 December 2017 00:50 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Stefano Stabellini > ; George Dunlap ; > Andrew Cooper

Re: [Xen-devel] [PATCH v15 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

>>> On 14.12.17 at 18:41, wrote: > Certain memory resources associated with a guest are not necessarily > present in the guest P2M. > > This patch adds the boilerplate for new memory op to allow such a resource > to be priv-mapped directly, by either a PV or HVM tools