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

flight 117022 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117022/ 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] [linux-arm-xen test] 116992: tolerable all pass - PUSHED

flight 116992 linux-arm-xen real [real] http://logs.test-lab.xenproject.org/osstest/logs/116992/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 107552 test-armhf-armhf-libvirt 14

[Xen-devel] [xen-unstable baseline-only test] 72527: regressions - FAIL

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

[Xen-devel] [xen-4.10-testing test] 116961: regressions - FAIL

flight 116961 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116961/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 116762 Tests which

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

flight 117015 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117015/ 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] [Qemu-devel] [PATCH] xen/pt: Set is_express to avoid out-of-bounds write

On Sat, 28 Oct 2017, Simon Gaiser wrote: > The passed-through device might be an express device. In this case the > old code allocated a too small emulated config space in > pci_config_alloc() since pci_config_size() returned the size for a > non-express device. This leads to an out-of-bound write

Re: [Xen-devel] [PATCH for-next 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache

On 8 Dec 2017 22:26, "Stefano Stabellini" wrote: On Fri, 8 Dec 2017, Julien Grall wrote: > On 06/12/17 12:27, Julien Grall wrote: > > On 12/06/2017 01:26 AM, Stefano Stabellini wrote: > > > On Thu, 23 Nov 2017, Julien Grall wrote: > > > > Hi Andrew, > > > > > > > > On

Re: [Xen-devel] [PATCH for-next 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache

On Fri, 8 Dec 2017, Julien Grall wrote: > On 06/12/17 12:27, Julien Grall wrote: > > On 12/06/2017 01:26 AM, Stefano Stabellini wrote: > > > On Thu, 23 Nov 2017, Julien Grall wrote: > > > > Hi Andrew, > > > > > > > > On 23/11/17 18:49, Andrew Cooper wrote: > > > > > On 23/11/17 18:32, Julien

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

On Thu, Dec 07, 2017 at 05:21:44PM -0500, Govinda Tatti wrote: > This patch exports pcie_has_flr() and it is being used by Xen pciback > driver to reset (flr/slot/bus) PCI devices based on 'reset' SysFS > attribute. > > Signed-off-by: Govinda Tatti > --- > v3: -New > >

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

On 12/07/2017 05:45 PM, Maran Wilson wrote: > > Juergen also had a suggestion to split the different hypervisor types > early and use a common set of service functions instead of special casing > xen_guest everywhere. > > There are certainly less special cases in this version of the patch, but >

Re: [Xen-devel] [RFC PATCH v2 1/2] xen/pvh: Add memory map pointer to hvm_start_info struct

Thanks for taking a look Jan. More below... On 12/8/2017 12:49 AM, Jan Beulich wrote: On 07.12.17 at 23:45, wrote: The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also

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

flight 116958 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116958/ 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 are

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

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

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

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

[Xen-devel] [xen-unstable test] 116952: tolerable FAIL - PUSHED

flight 116952 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/116952/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 116891 Tests which did not

Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages

On Fri, Dec 8, 2017 at 5:42 AM, Razvan Cojocaru wrote: > On 12/08/2017 02:18 PM, Jan Beulich wrote: > On 24.10.17 at 12:19, wrote: >>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a >>> DOMCTL) for

Re: [Xen-devel] [PATCH for-next 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache

Hi, On 06/12/17 12:27, Julien Grall wrote: On 12/06/2017 01:26 AM, Stefano Stabellini wrote: On Thu, 23 Nov 2017, Julien Grall wrote: Hi Andrew, On 23/11/17 18:49, Andrew Cooper wrote: On 23/11/17 18:32, Julien Grall wrote: This new function will be used in a follow-up patch to copy data to

Re: [Xen-devel] [PATCH for-next 06/16] xen/arm: Extend copy_to_guest to support copying from/to guest physical address

Hi Stefano, On 07/12/17 23:01, Stefano Stabellini wrote: On Wed, 6 Dec 2017, Julien Grall wrote: Hi Stefano, On 12/06/2017 01:22 AM, Stefano Stabellini wrote: On Thu, 23 Nov 2017, Julien Grall wrote: The only differences between copy_to_guest and access_guest_memory_by_ipa are: - The

Re: [Xen-devel] [PATCH] xen/arm: Surround HSR_SYSREG macro value with ()

Hi, Ping? Cheers, On 29/11/17 17:46, Julien Grall wrote: The value of the macro HCR_SYSREG is not surrounded by (). This means the behavior may change depend on how it is used. Thanksfully recent GCC will issue a warning for that. Signed-off-by: Julien Grall ---

[Xen-devel] [PATCH v3 1/4] x86/boot: add acpi rsdp address to setup_header

Xen PVH guests receive the address of the RSDP table from Xen. In order to support booting a Xen PVH guest via Grub2 using the standard x86 boot entry we need a way for Grub2 to pass the RSDP address to the kernel. For this purpose expand the struct setup_header to hold the physical address of

[Xen-devel] [PATCH v3 4/4] x86/xen: supply rsdp address in boot params for pvh guests

When booted via the special PVH entry save the RSDP address set in the boot information block in struct boot_params. This will enable Xen to locate the RSDP at an arbitrary address. Set the boot loader version to 2.14 (0x020e) replacing the wrong 0x0212 which should have been 0x020c.

[Xen-devel] [PATCH v3 0/4] x86: make rsdp address accessible via boot params

In the non-EFI boot path the ACPI RSDP table is currently found via either EBDA or by searching through low memory for the RSDP magic. This requires the RSDP to be located in the first 1MB of physical memory. Xen PVH guests, however, get the RSDP address via the start of day information block. In

[Xen-devel] [PATCH v3 3/4] x86/xen: fix boot loader version reported for pvh guests

The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Cc:

[Xen-devel] linux-xen-arm branch update

On 05/12/17 18:42, Julien Grall wrote: Hi Ian, On 05/12/17 18:41, Ian Jackson wrote: Stefano Stabellini writes ("Re: [OSSTEST PATCH] linux-arm-xen: Get from shared arm/linux.git xenbits tree"): On Tue, 5 Dec 2017, Julien Grall wrote: Acked-by: Julien Grall

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

On 08/12/17 08:03, Tim Deegan wrote: Hi, Hi Tim, Somehow your e-mail was marked as spam by gmail. At 12:58 + on 06 Dec (1512565090), Julien Grall wrote: On 12/06/2017 12:28 PM, George Dunlap wrote: 2. It sounds like rather than using PoD, you could use the "misconfigured p2m table"

Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages

On 12/08/2017 02:18 PM, Jan Beulich wrote: On 24.10.17 at 12:19, wrote: >> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a >> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and >> hence with the original

Re: [Xen-devel] [PATCH v2 07/13] iommu: Make decision about needing IOMMU for hardware domains in advance

Hi, Jan On Thu, Dec 7, 2017 at 3:57 PM, Jan Beulich wrote: On 07.12.17 at 14:50, wrote: >> On Thu, Dec 7, 2017 at 10:57 AM, Jan Beulich wrote: >> On 06.12.17 at 20:23, wrote: On Wed, Dec 6, 2017 at

Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages

>>> On 24.10.17 at 12:19, wrote: > HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a > DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and > hence with the original altp2m design, where domains are allowed - with the

Re: [Xen-devel] [RFC PATCH 06/31] cpufreq: make cpufreq driver more generalizable

Hi Jan On Fri, Dec 8, 2017 at 10:07 AM, Jan Beulich wrote: On 07.12.17 at 21:31, wrote: >> Have questions which need to be clarified: >> >> If I understood correctly, new variant of set_px_pminfo is going to >> have an extra "flag" argument, since >>

Re: [Xen-devel] [PATCH v2 2/3] x86/acpi: take rsdp address for boot params if available

On 08/12/17 12:26, Ingo Molnar wrote: > > * Juergen Gross wrote: > >> On 08/12/17 08:05, Ingo Molnar wrote: >>> >>> * Juergen Gross wrote: >> >> ... >> >>> acpi_physical_address acpi_arch_get_root_pointer(void) >>> { >>> return

Re: [Xen-devel] [PATCH v2 2/3] x86/acpi: take rsdp address for boot params if available

On 08/12/17 08:05, Ingo Molnar wrote: > > * Juergen Gross wrote: ... > acpi_physical_address acpi_arch_get_root_pointer(void) > { > return boot_params.hdr.acpi_rsdp_addr; > } > > 4) > > Add this to arch/x86/include/asm/acpi.h: > > extern acpi_physical_address

Re: [Xen-devel] [PATCH v3 19/25] x86emul: tell cmpxchg hook whether LOCK is in effect

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 07 December 2017 14:14 > To: xen-devel > Cc: Andrew Cooper ; Paul Durrant > ; George Dunlap ; > Tim

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

On 12/07/2017 07:21 PM, Marc Zyngier wrote: > On 07/12/17 18:06, George Dunlap wrote: >> On 12/07/2017 04:58 PM, Marc Zyngier wrote: >>> On 07/12/17 16:44, George Dunlap wrote: On 12/07/2017 04:04 PM, Julien Grall wrote: > Hi Jan, > > On 07/12/17 15:45, Jan Beulich wrote:

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

flight 116949 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/116949/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 116145

Re: [Xen-devel] [PATCH v3 23/25] x86/HVM: make use of new read-modify-write emulator hook

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 07 December 2017 14:18 > To: xen-devel > Cc: Andrew Cooper ; Paul Durrant > ; George Dunlap > Subject:

Re: [Xen-devel] [PATCH v3 22/25] x86/HVM: do actual CMPXCHG in hvmemul_cmpxchg()

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 07 December 2017 14:17 > To: xen-devel > Cc: Andrew Cooper ; Paul Durrant > ; George Dunlap > Subject:

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

>>> On 07.12.17 at 23:21, wrote: > Due to the complexity with the PCI lock we cannot do the reset when a > device is bound ('echo $BDF > bind') or when unbound ('echo $BDF > unbind') > as the pci_[slot|bus]_reset also takes the same lock resulting in a > dead-lock. It

Re: [Xen-devel] [PATCH v2 1/3] x86/boot: add acpi rsdp address to setup_header

* Juergen Gross wrote: > >> +Offset/size: 0x268/8 > >> +Protocol: 2.14+ > >> + > >> + This field can be set by the boot loader to tell the kernel the > >> + physical address of the ACPI RSDP table. > >> + > >> + A value of 0 indicates the kernel should fall back to the

Re: [Xen-devel] [PATCH v2 3/3] x86/xen: supply rsdp address in boot params for pvh guests

On 08/12/17 08:22, Ingo Molnar wrote: > > * Juergen Gross wrote: > >> When booted via the special PVH entry save the RSDP address set in the >> boot information block in struct boot_params. This will enable Xen to >> locate the RSDP at an arbitrary address. >> >> Set the boot

Re: [Xen-devel] [PATCH v2 1/3] x86/boot: add acpi rsdp address to setup_header

On 08/12/17 08:16, Ingo Molnar wrote: > > * Juergen Gross wrote: > >> Xen PVH guests receive the address of the RSDP table from Xen. In order >> to support booting a Xen PVH guest via grub2 using the standard x86 >> boot entry we need a way fro grub2 to pass the RSDP address to

Re: [Xen-devel] [PATCH v2 1/3] x86/boot: add acpi rsdp address to setup_header

>>> On 08.12.17 at 08:16, wrote: > Also, a more fundamental question: why doesn't Xen use EFI to hand over > hardware configuration details? Iirc the main purpose of the change here is to allow booting PVH (guest or Dom0) with Grub2 in the middle. PVH, at least for the time

Re: [Xen-devel] [PATCH v2 2/3] x86/acpi: take rsdp address for boot params if available

On 08/12/17 08:05, Ingo Molnar wrote: > > * Juergen Gross wrote: > >> In case the rsdp address in struct boot_params is specified don't try >> to find the table by searching, but take the address directly as set >> by the boot loader. >> >> Signed-off-by: Juergen Gross

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

Hi, At 12:58 + on 06 Dec (1512565090), Julien Grall wrote: > On 12/06/2017 12:28 PM, George Dunlap wrote: > > 2. It sounds like rather than using PoD, you could use the > > "misconfigured p2m table" technique that x86 uses: set bits in the p2m > > entry which cause a specific kind of HAP