Re: [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

>>> On 26.01.17 at 19:39, wrote: > Does the below answer your question? I think that's fine, once added to the actual patch description. Jan > On 01/05/2017 08:07 PM, Oleksandr Andrushchenko wrote: >> On 01/05/2017 06:12 PM, Jan Beulich wrote: >> On 05.01.17 at 17:03, wrote: On 01/05/

Re: [Xen-devel] [PATCH v2] xen, input: try to read screen resolution for xen-kbdfront

On 01/27/2017 09:46 AM, Juergen Gross wrote: On 27/01/17 08:21, Oleksandr Andrushchenko wrote: On 01/27/2017 09:12 AM, Juergen Gross wrote: Instead of using the default resolution of 800*600 for the pointing device of xen-kbdfront try to read the resolution of the (virtual) framebuffer device.

Re: [Xen-devel] Xen on lager for DOMU

On 01/26/2017 09:11 PM, Julien Grall wrote: On 24/01/2017 13:05, George John wrote: Hi all, Hello, I was able to bring up Dom0 in lager board by steps followed by charles. What could be the steps I could follow to bring up DomU in xen for lager board.?.. You can give a look to: - ht

Re: [Xen-devel] [PATCH v2] xen, input: try to read screen resolution for xen-kbdfront

On 27/01/17 08:21, Oleksandr Andrushchenko wrote: > On 01/27/2017 09:12 AM, Juergen Gross wrote: >> Instead of using the default resolution of 800*600 for the pointing >> device of xen-kbdfront try to read the resolution of the (virtual) >> framebuffer device. Use the default as fallback only. >> >

Re: [Xen-devel] [PATCH v2] xen, input: try to read screen resolution for xen-kbdfront

On 01/27/2017 09:12 AM, Juergen Gross wrote: Instead of using the default resolution of 800*600 for the pointing device of xen-kbdfront try to read the resolution of the (virtual) framebuffer device. Use the default as fallback only. Signed-off-by: Juergen Gross --- V2: get framebuffer resoluti

[Xen-devel] [PATCH v2] xen, input: try to read screen resolution for xen-kbdfront

Instead of using the default resolution of 800*600 for the pointing device of xen-kbdfront try to read the resolution of the (virtual) framebuffer device. Use the default as fallback only. Signed-off-by: Juergen Gross --- V2: get framebuffer resolution only if CONFIG_FB (Dmitry Torokhov) --- dri

Re: [Xen-devel] [DOC v8] PV Calls protocol design

Hi, Stefano! Error numbers The numbers corresponding to the error names specified by POSIX are: [EPERM] -1 [ENOENT]-2 Don't you want to use Xen's errno.h here as described in [1]? So we have error codes consistent for all PV protocols? Thanks, Oleksandr [1] ht

Re: [Xen-devel] [PATCH] xen, input: try to read screen resolution for xen-kbdfront

On 24/01/17 19:47, Dmitry Torokhov wrote: > On Tue, Jan 24, 2017 at 01:09:55PM +0100, Juergen Gross wrote: >> Instead of using the default resolution of 800*600 for the pointing >> device of xen-kbdfront try to read the resolution of the (virtual) >> framebuffer device. Use the default as fallback

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

flight 104728 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104728/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 104681 test-amd64-a

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

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

Re: [Xen-devel] [PATCH v3] arm/p2m: Fix regression during domain shutdown with active mem_access

On Wed, 25 Jan 2017, Julien Grall wrote: > Hi Tamas, > > On 25/01/2017 16:12, Tamas K Lengyel wrote: > > The change in commit 438c5fe4f0c introduced a regression for domains where > > mem_acces is or was active. When relinquish_p2m_mapping attempts to clear > > a page where the order is not 0 the

[Xen-devel] [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

When the toolstack modifies memory of a running ARM VM it may happen that the underlying memory of a current vCPU PC is changed. Without flushing the icache the vCPU may continue executing stale instructions. In this patch we introduce VA-based icache flushing macros. Also expose the xc_domain_cac

Re: [Xen-devel] [PATCH] xen: sched: improve debug dump output.

On Thu, 2017-01-26 at 13:59 -0500, Meng Xu wrote: > Hi Dario, > Hi, > On Thu, Jan 26, 2017 at 11:52 AM, Dario Faggioli > wrote: > > > >  Runqueue 0: > >  CPU[00] runq=0, sibling=,0003, core=,00ff > > run: [0.15] flags=2 cpu=0 credit=5804742 [w=256] load=3655 > > (~1%)

[Xen-devel] CfP Virtualization in High-Performance Cloud Computing Workshop (VHPC '17)

CALL FOR PAPERS 12th Workshop on Virtualization in High­-Performance Cloud Computing (VHPC '17) held in conjunction with the International Supercomputing Conference - High Performance, June 18-22, 2017, Frankfurt, Germany.

Re: [Xen-devel] [Qemu-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen

On 26 January 2017 at 20:47, Peter Maydell wrote: > On 26 January 2017 at 19:36, Stefano Stabellini > wrote: >> It should be just a matter of replacing qdev_init_nofail with something >> that can fail. I couldn't find a regular qdev_init that can return >> error, so maybe we would need to add it

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

Hi, On 26/01/2017 19:01, Boris Ostrovsky wrote: On 01/26/2017 12:18 PM, Ian Jackson wrote: Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL"): On 01/26/2017 08:23 AM, osstest service owner wrote: flight 104684 linux-linus real [real] http://logs.test-lab

Re: [Xen-devel] [Qemu-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen

On 26 January 2017 at 19:36, Stefano Stabellini wrote: > It should be just a matter of replacing qdev_init_nofail with something > that can fail. I couldn't find a regular qdev_init that can return > error, so maybe we would need to add it. That's just object_property_set_bool(OBJECT(whatever

Re: [Xen-devel] [PATCH v1 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes

On 01/26/2017 05:25 PM, Andy Lutomirski wrote: > On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins > wrote: >> This file defines an ABI shared between guest and hypervisor(s) >> (KVM, Xen) and as such there should be an correspondent entry in >> MAINTAINERS file. Notice that there's already a text no

Re: [Xen-devel] [PATCH v1 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va

On 01/26/2017 05:25 PM, Andy Lutomirski wrote: > On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins > wrote: >> Right now there is only a pvclock_pvti_cpu0_va() which is defined >> on kvmclock since: >> >> commit dac16fba6fc5 >> ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap") >>

[Xen-devel] [PATCH v2 1/9] x86/boot/32: Convert the 32-bit pgtable setup code from assembly to C

The new Xen PVH entry point requires page tables to be setup by the kernel since it is entered with paging disabled. Pull the common code out of head_32.S so that mk_early_pgtbl_32() can be invoked from both the new Xen entry point and the existing startup_32() code. Convert resulting common code

[Xen-devel] [PATCH v2 6/9] xen/pvh: Initialize grant table for PVH guests

Like PV guests, PVH does not have PCI devices and therefore cannot use MMIO space to store grants. Instead it balloons out memory and keeps grants there. Signed-off-by: Boris Ostrovsky --- Changes in v2: * Updated commit message drivers/xen/grant-table.c | 8 1 file changed, 4 insertio

[Xen-devel] [PATCH v2 4/9] xen/pvh: Bootstrap PVH guest

Start PVH guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall page, initialize boot_params, enable early page tables. Since this stub is executed before kernel entry point we cannot use variables in .bss which is cleared by kernel. We explicitly place variables that are initialized here int

[Xen-devel] [PATCH v2 8/9] xen/pvh: Enable CPU hotplug

PVH guests don't (yet) receive ACPI hotplug interrupts and therefore need to monitor xenstore for CPU hotplug event. Signed-off-by: Boris Ostrovsky --- drivers/xen/cpu_hotplug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplu

[Xen-devel] [PATCH v2 9/9] xen/pvh: Use Xen's emergency_restart op for PVH guests

Using native_machine_emergency_restart (called during reboot) will lead PVH guests to machine_real_restart() where we try to use real_mode_header which is not initialized. Signed-off-by: Boris Ostrovsky --- New in v2 arch/x86/xen/enlighten.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[Xen-devel] [PATCH v2 7/9] xen/pvh: PVH guests always have PV devices

Signed-off-by: Boris Ostrovsky Reviewed-by: Juergen Gross Reviewed-by: Konrad Rzeszutek Wilk --- arch/x86/xen/platform-pci-unplug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c index 90d1b83..33a

[Xen-devel] [PATCH v2 0/9] PVH v2 support (domU)

PVH v2 support for unprivileged guests. Now that we decided to defer ACPI CPU hotplug until we understand better what to do about it in dom0 I am sending v2 with PV-style CPU hotplug, with v1 comments addressed. Boris Ostrovsky (9): x86/boot/32: Convert the 32-bit pgtable setup code from assem

[Xen-devel] [PATCH v2 5/9] xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC

Make sure they don't use these devices since they are not emulated for unprivileged PVH guest. Also don't initialize hypercall page for them in init_hvm_pv_info() since this has already been done. Signed-off-by: Boris Ostrovsky --- Changes in v2: * Use cpuid_ebx() instead of cpuid() arch/x86/x

[Xen-devel] [PATCH v2 3/9] xen/pvh: Import PVH-related Xen public interfaces

Signed-off-by: Boris Ostrovsky Reviewed-by: Juergen Gross Reviewed-by: Konrad Rzeszutek Wilk --- include/xen/interface/elfnote.h| 12 ++- include/xen/interface/hvm/hvm_vcpu.h | 143 + include/xen/interface/hvm/start_info.h | 98 ++

[Xen-devel] [PATCH v2 2/9] xen/x86: Remove PVH support

We are replacing existing PVH guests with new implementation. We are keeping xen_pvh_domain() macro (for now set to zero) because when we introduce new PVH implementation later in this series we will reuse current PVH-specific code (xen_pvh_gnttab_setup()), and that code is conditioned by 'if (xen

Re: [Xen-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen

On Thu, 26 Jan 2017, Roger Pau Monné wrote: > On Wed, Jan 25, 2017 at 11:05:29AM +, Roger Pau Monné wrote: > > On Tue, Jan 24, 2017 at 01:30:02PM -0800, Stefano Stabellini wrote: > > > On Tue, 24 Jan 2017, Stefano Stabellini wrote: > > > > On Tue, 24 Jan 2017, Roger Pau Monné wrote: > > > > > H

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

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

Re: [Xen-devel] Xen installation on Nvidia Jetson TK-1

On 24/01/2017 05:48, Methuku Karthik wrote: Hello, Hello, Please don't use HTML in your e-mail. Plain text is the standard on mailing list. I am trying to install xen on Nvidia Jetson TK1. I am using this repo /git://xenbits.xen.org/people/ianc/xen.git

Re: [Xen-devel] Xen on lager for DOMU

On 24/01/2017 13:05, George John wrote: Hi all, Hello, I was able to bring up Dom0 in lager board by steps followed by charles. What could be the steps I could follow to bring up DomU in xen for lager board.?.. You can give a look to: - https://wiki.xen.org/wiki/Mainline_Linux_Ke

Re: [Xen-devel] [PATCH v2 2/3] x86: Remap GDT tables in the Fixmap section

On Thu, Jan 26, 2017 at 10:52 AM, Andy Lutomirski wrote: > On Thu, Jan 26, 2017 at 8:59 AM, Thomas Garnier wrote: >> Each processor holds a GDT in its per-cpu structure. The sgdt >> instruction gives the base address of the current GDT. This address can >> be used to bypass KASLR memory randomiza

[Xen-devel] [xen-4.4-testing baseline-only test] 68467: tolerable FAIL

This run is configured for baseline tests only. flight 68467 xen-4.4-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68467/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-amd64-rumprun-amd64 1 build-chec

Re: [Xen-devel] [PATCH] arm/monitor: flush the icache during SMC traps

On Thu, Jan 26, 2017 at 10:54 AM, Tamas K Lengyel wrote: > On Thu, Jan 26, 2017 at 4:30 AM, Julien Grall wrote: >> (CC xen-devel, Ravzan, and Stefao) >> >> Hi Tamas, >> >> Not sure why you only CC me on the answer. I have CCed again xen-devel as I >> don't see any sensible discussion in it. >> >>

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

On 01/26/2017 12:18 PM, Ian Jackson wrote: > Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104684: > regressions - FAIL"): >> On 01/26/2017 08:23 AM, osstest service owner wrote: >>> flight 104684 linux-linus real [real] >>> http://logs.test-lab.xenproject.org/osstest/logs/104684/ >>

Re: [Xen-devel] [PATCH] xen: sched: improve debug dump output.

Hi Dario, I'm commenting on the rtds part. On Thu, Jan 26, 2017 at 11:52 AM, Dario Faggioli wrote: > Scheduling information debug dump for Credit2 is hard > to read as it contains the same information repeated > multiple time in different ways. > > In fact, in Credit2, CPUs are grouped in runque

Re: [Xen-devel] [PATCH v2 2/3] x86: Remap GDT tables in the Fixmap section

On Thu, Jan 26, 2017 at 8:59 AM, Thomas Garnier wrote: > Each processor holds a GDT in its per-cpu structure. The sgdt > instruction gives the base address of the current GDT. This address can > be used to bypass KASLR memory randomization. With another bug, an > attacker could target other per-cp

Re: [Xen-devel] POSIX error names and codes in PV protocols

On 01/26/2017 08:16 PM, Roger Pau Monné wrote: On Thu, Jan 26, 2017 at 08:14:10PM +0200, Oleksandr Andrushchenko wrote: On 01/26/2017 07:38 PM, Roger Pau Monné wrote: On Thu, Jan 26, 2017 at 07:28:44PM +0200, Oleksandr Andrushchenko wrote: On 01/26/2017 05:44 PM, Jan Beulich wrote: On 26.01

Re: [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

Hi, Jan! Does the below answer your question? Thank you, Oleksandr On 01/05/2017 08:07 PM, Oleksandr Andrushchenko wrote: On 01/05/2017 06:12 PM, Jan Beulich wrote: On 05.01.17 at 17:03, wrote: On 01/05/2017 05:45 PM, Jan Beulich wrote: On 22.12.16 at 09:12, wrote: Other than that the pr

Re: [Xen-devel] POSIX error names and codes in PV protocols

On Thu, Jan 26, 2017 at 08:14:10PM +0200, Oleksandr Andrushchenko wrote: > On 01/26/2017 07:38 PM, Roger Pau Monné wrote: > > On Thu, Jan 26, 2017 at 07:28:44PM +0200, Oleksandr Andrushchenko wrote: > > > On 01/26/2017 05:44 PM, Jan Beulich wrote: > > > > > > > On 26.01.17 at 15:40, wrote: > > > >

Re: [Xen-devel] POSIX error names and codes in PV protocols

On 01/26/2017 07:38 PM, Roger Pau Monné wrote: On Thu, Jan 26, 2017 at 07:28:44PM +0200, Oleksandr Andrushchenko wrote: On 01/26/2017 05:44 PM, Jan Beulich wrote: On 26.01.17 at 15:40, wrote: There is some work happening on new PV protocols: sndif [1], displif [2], PV calls [3] and the commo

[Xen-devel] [PATCH] x86/xen: Fix APIC id mismatch warning on Intel

This patch fixes the following warning message seen when booting the kernel as Dom0 with Xen on Intel machines. [0.003000] [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 0 APIC: 1] The code generating the warning in validate_apic_and_package_id() matches cpu_data(cpu).apicid (initialized in i

Re: [Xen-devel] [PATCH] flask: fix build after the introduction of DMOP

On 01/25/2017 05:43 AM, Wei Liu wrote: In 58cbc034 send_irq permission was removed but there was still reference to it in policy file. Remove the stale reference. And now we also need dm permission. Add that. Signed-off-by: Wei Liu Acked-by: Daniel De Graaf ___

Re: [Xen-devel] [PATCH] [incremental] xsm/build: Further build fixes following the DMop series

On 01/25/2017 09:24 AM, Andrew Cooper wrote: Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Daniel De Graaf CC: Paul Durrant CC: Ian Jackson Might be better to merge into one single patch when committed? Either way (combined with prior patch, original series, or alone): Acked-by: D

Re: [Xen-devel] [PATCH] arm/monitor: flush the icache during SMC traps

On Thu, Jan 26, 2017 at 4:30 AM, Julien Grall wrote: > (CC xen-devel, Ravzan, and Stefao) > > Hi Tamas, > > Not sure why you only CC me on the answer. I have CCed again xen-devel as I > don't see any sensible discussion in it. > > On 26/01/2017 00:11, Tamas K Lengyel wrote: >> >> On Wed, Jan 25, 2

Re: [Xen-devel] POSIX error names and codes in PV protocols

On Thu, Jan 26, 2017 at 07:28:44PM +0200, Oleksandr Andrushchenko wrote: > On 01/26/2017 05:44 PM, Jan Beulich wrote: > > > > > On 26.01.17 at 15:40, wrote: > > > There is some work happening on new PV protocols: sndif [1], > > > > > > displif [2], PV calls [3] and the common part of those is tha

Re: [Xen-devel] POSIX error names and codes in PV protocols

Hi, On 26/01/2017 17:28, Oleksandr Andrushchenko wrote: On 01/26/2017 05:44 PM, Jan Beulich wrote: On 26.01.17 at 15:40, wrote: There is some work happening on new PV protocols: sndif [1], displif [2], PV calls [3] and the common part of those is that error/status codes must be returned as

Re: [Xen-devel] POSIX error names and codes in PV protocols

On 01/26/2017 05:44 PM, Jan Beulich wrote: On 26.01.17 at 15:40, wrote: There is some work happening on new PV protocols: sndif [1], displif [2], PV calls [3] and the common part of those is that error/status codes must be returned as a part of a response packet. For that Konrad suggested [1

Re: [Xen-devel] [PATCH v1 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va

On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins wrote: > Right now there is only a pvclock_pvti_cpu0_va() which is defined > on kvmclock since: > > commit dac16fba6fc5 > ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap") > > The only user of this interface was kvm. This commit mo

Re: [Xen-devel] [PATCH v1 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes

On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins wrote: > This file defines an ABI shared between guest and hypervisor(s) > (KVM, Xen) and as such there should be an correspondent entry in > MAINTAINERS file. Notice that there's already a text notice at the > top of the header file, hence this commit

Re: [Xen-devel] [PATCH] flask: fix build after the introduction of DMOP

On Thu, Jan 26, 2017 at 10:22:52AM +, Wei Liu wrote: > On Wed, Jan 25, 2017 at 10:43:11AM +, Wei Liu wrote: > > In 58cbc034 send_irq permission was removed but there was still > > reference to it in policy file. Remove the stale reference. > > > > And now we also need dm permission. Add th

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL"): > On 01/26/2017 08:23 AM, osstest service owner wrote: > > flight 104684 linux-linus real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/104684/ > > > > Regressions :-( > > > > Tests which did no

Re: [Xen-devel] [PATCH v1 2/3] x86/xen/time: setup vcpu 0 time info page

On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins wrote: > In order to support pvclock vdso on xen we need to setup the time > info page for vcpu 0 and register the page with Xen using the > VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall > will also forcefully update the pvti which wi

[Xen-devel] [xen-unstable-smoke test] 104722: regressions - trouble: blocked/broken/fail

flight 104722 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104722/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf

Re: [Xen-devel] Xen 4.9 Development Update

On Thu, Jan 26, 2017 at 12:27:15PM +, Julien Grall wrote: > Hi, > > On 09/12/2016 19:09, Andrew Cooper wrote: > > On 09/12/16 19:01, Stefano Stabellini wrote: > > > On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote: > > > > On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote: > > > > > On Fri, Dec 0

[Xen-devel] [PATCH v2 2/3] x86: Remap GDT tables in the Fixmap section

Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target other per-cpu structures or deduce the base of the main memory section (PAGE

[Xen-devel] [PATCH v2 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

This patch aligns MODULES_END to the beginning of the Fixmap section. It optimizes the space available for both sections. The address is pre-computed based on the number of pages required by the Fixmap section. It will allow GDT remapping in the Fixmap section. The current MODULES_END static addre

[Xen-devel] [PATCH v2 3/3] x86: Make the GDT remapping read-only on 64 bit

This patch makes the GDT remapped pages read-only to prevent corruption. This change is done only on 64 bit. The native_load_tr_desc function was adapted to correctly handle a read-only GDT. The LTR instruction always writes to the GDT TSS entry. This generates a page fault if the GDT is read-only

Re: [Xen-devel] [PATCH v2 3/8] hw: Default -drive to if=none instead of ide when ide cannot work

Le 26/01/2017 à 16:09, Markus Armbruster a écrit : > Block backends defined with -drive if=ide are meant to be picked up by > machine initialization code: a suitable frontend gets created and > wired up automatically. > > if=ide drives not picked up that way can still be used with -device as > if

[Xen-devel] [PATCH] xen: sched: improve debug dump output.

Scheduling information debug dump for Credit2 is hard to read as it contains the same information repeated multiple time in different ways. In fact, in Credit2, CPUs are grouped in runqueus. Here's the current debug output: CPU[00] sibling=,0003, core=,00ff run: [327

Re: [Xen-devel] [PATCH 5/7] fuzz/x86emul: update fuzzer

On 26/01/17 14:33, Jan Beulich wrote: +return X86EMUL_EXCEPTION; +else +{ +if ( input.data[data_index] > 0xc ) +rc = X86EMUL_EXCEPTION; +else if ( input.data[data_index] > 0x8 ) +rc = X86EMUL_UNHANDLEABLE; >>

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

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

[Xen-devel] [OSSTEST PATCH] bisection: Really avoid flail

The flail detector needs to search for flights which will look like the one it is creating, when this one is done. The intended blessing always lacks `-bisect' so is no use. We can use the last blessing for this: both cr-try-bisect and cr-try-bisect-adhoc pass the same value for the last blessing

Re: [Xen-devel] [PATCH v5 3/9] xen/x86: split Dom0 build into PV and PVHv2

On Thu, Jan 26, 2017 at 04:43:37AM -0700, Jan Beulich wrote: > >>> On 19.01.17 at 18:29, wrote: > > --- a/xen/arch/x86/domain_build.c > > +++ b/xen/arch/x86/domain_build.c > > @@ -191,11 +191,40 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain > > *dom0) > > } > > > > #ifdef CONFIG_SHADO

Re: [Xen-devel] [PATCH] x86/dmar: place the initdata annotation after the variable type

>>> On 26.01.17 at 17:18, wrote: > clang cannot cope with the annotation being in the middle of the variable > declaration. > > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich > --- a/xen/drivers/passthrough/vtd/dmar.c > +++ b/xen/drivers/passthrough/vtd/dmar.c > @@ -871,8 +871,8 @@ s

Re: [Xen-devel] [PATCH] x86/dmar: place the initdata annotation after the variable type

On 26/01/17 16:18, Roger Pau Monne wrote: > clang cannot cope with the annotation being in the middle of the variable > declaration. > > Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https

[Xen-devel] [PATCH] x86/dmar: place the initdata annotation after the variable type

clang cannot cope with the annotation being in the middle of the variable declaration. Signed-off-by: Roger Pau Monné --- Cc: Kevin Tian Cc: Feng Wu Cc: Jan Beulich Cc: Andrew Cooper --- xen/drivers/passthrough/vtd/dmar.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Xen-devel] [xen-unstable-smoke test] 104716: regressions - trouble: blocked/broken/fail

flight 104716 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104716/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf

Re: [Xen-devel] Pausing / unpausing a single domain VCPU via libxc

On 01/26/2017 06:00 PM, Dario Faggioli wrote: > On Thu, 2017-01-26 at 17:42 +0200, Razvan Cojocaru wrote: >> On 01/26/2017 05:14 PM, Dario Faggioli wrote: >>> You mean you'd want to implement xc_vcpu_pause() by means of >>> the XEN_DOMCTL_gdbsx_pausevcpu? >>> >>> What's the use case for that, and d

Re: [Xen-devel] Pausing / unpausing a single domain VCPU via libxc

On Thu, 2017-01-26 at 17:42 +0200, Razvan Cojocaru wrote: > On 01/26/2017 05:14 PM, Dario Faggioli wrote: > > You mean you'd want to implement xc_vcpu_pause() by means of > > the XEN_DOMCTL_gdbsx_pausevcpu? > > > > What's the use case for that, and does it fit with the > > implementation > > of sa

Re: [Xen-devel] [Qemu-devel] [PATCH v2 3/8] hw: Default -drive to if=none instead of ide when ide cannot work

On 26.01.2017 16:09, Markus Armbruster wrote: > Block backends defined with -drive if=ide are meant to be picked up by > machine initialization code: a suitable frontend gets created and > wired up automatically. > > if=ide drives not picked up that way can still be used with -device as > if they

Re: [Xen-devel] Pausing / unpausing a single domain VCPU via libxc

>>> On 26.01.17 at 13:08, wrote: > I see that there's currently no xc_vcpu_pause() (there's only > xc_domain_pause(), which freezes all the VCPUs), but there's > XEN_DOMCTL_gdbsx_pausevcpu, which is only used by > tools/debugger/gdbsx/xg/xg_main.c. > > Wouldn't it make sense to have a "regular" D

Re: [Xen-devel] [PATCH v3] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again

>>> On 26.01.17 at 15:50, wrote: > From: David Woodhouse > > For some MMIO regions, such as those high above RAM, mfn_valid() will > return false. > > Since the fix for XSA-154 in commit c61a6f74f80e ("x86: enforce > consistent cachability of MMIO mappings"), guests have no longer been > able t

Re: [Xen-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen

On Wed, Jan 25, 2017 at 11:05:29AM +, Roger Pau Monné wrote: > On Tue, Jan 24, 2017 at 01:30:02PM -0800, Stefano Stabellini wrote: > > On Tue, 24 Jan 2017, Stefano Stabellini wrote: > > > On Tue, 24 Jan 2017, Roger Pau Monné wrote: > > > > Hello, > > > > > > > > The following commit: > > > >

Re: [Xen-devel] POSIX error names and codes in PV protocols

>>> On 26.01.17 at 15:40, wrote: > There is some work happening on new PV protocols: sndif [1], > > displif [2], PV calls [3] and the common part of those is that > > error/status codes must be returned as a part of a response packet. > > For that Konrad suggested [1] (and Stefano already used

[Xen-devel] [xen-unstable-smoke test] 104713: regressions - trouble: blocked/broken/fail

flight 104713 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104713/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf

Re: [Xen-devel] Pausing / unpausing a single domain VCPU via libxc

On 01/26/2017 05:14 PM, Dario Faggioli wrote: > [Adding tools people, and Andrew's which, according to git history, > has touched the involved (Xen) code for last :-) ] > > On Thu, 2017-01-26 at 14:08 +0200, Razvan Cojocaru wrote: >> Hello, >> >> I see that there's currently no xc_vcpu_pause() (t

[Xen-devel] [xen-4.3-testing baseline-only test] 68466: tolerable trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 68466 xen-4.3-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68466/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-amd64-rumprun-amd64 1 build-chec

[Xen-devel] [PATCH] libs/gnttab: add FreeBSD handlers for the grant-table user-space device

This patch adds the headers and helpers for the FreeBSD gntdev, used in order to map grants from remote domains and to allocate grants on behalf of the current domain. Current code has been tested with the QEMU/Qdisk backend. Signed-off-by: Akshay Jaggi [ added dummy stub for osdep_gnttab_grant_

Re: [Xen-devel] Pausing / unpausing a single domain VCPU via libxc

[Adding tools people, and Andrew's which, according to git history,  has touched the involved (Xen) code for last :-) ] On Thu, 2017-01-26 at 14:08 +0200, Razvan Cojocaru wrote: > Hello, > > I see that there's currently no xc_vcpu_pause() (there's only > xc_domain_pause(), which freezes all the V

[Xen-devel] [PATCH v2 3/8] hw: Default -drive to if=none instead of ide when ide cannot work

Block backends defined with -drive if=ide are meant to be picked up by machine initialization code: a suitable frontend gets created and wired up automatically. if=ide drives not picked up that way can still be used with -device as if they had if=none, but that's unclean and best avoided. Unused

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

On 01/26/2017 08:23 AM, osstest service owner wrote: > flight 104684 linux-linus real [real] > http://logs.test-lab.xenproject.org/osstest/logs/104684/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-armhf-armhf-xl 6

[Xen-devel] [PATCH v3] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again

From: David Woodhouse For some MMIO regions, such as those high above RAM, mfn_valid() will return false. Since the fix for XSA-154 in commit c61a6f74f80e ("x86: enforce consistent cachability of MMIO mappings"), guests have no longer been able to use PAT to obtain write-combining on such region

Re: [Xen-devel] [PATCH v2] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again

On Thu, 2017-01-26 at 07:35 -0700, Jan Beulich wrote: > > Hmm, didn't you say you'd take care of the hard tabs? Er... yes. But it seems I neglected to specify whether I would also *save* the resulting file, 'git commit --amend', and actually send that version. Sorry. smime.p7s Description: S/MIM

Re: [Xen-devel] [PATCH v2] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again

>>> On 26.01.17 at 13:39, wrote: > --- a/xen/arch/x86/hvm/mtrr.c > +++ b/xen/arch/x86/hvm/mtrr.c > @@ -773,18 +773,20 @@ int epte_get_entry_emt(struct domain *d, unsigned long > gfn, mfn_t mfn, > if ( v->domain != d ) > v = d->vcpu ? d->vcpu[0] : NULL; > > -if ( !mfn_valid(mfn

[Xen-devel] POSIX error names and codes in PV protocols

Hi, all! There is some work happening on new PV protocols: sndif [1], displif [2], PV calls [3] and the common part of those is that error/status codes must be returned as a part of a response packet. For that Konrad suggested [1] (and Stefano already used in [3]) POSIX to be employed here in

Re: [Xen-devel] [PATCH 5/7] fuzz/x86emul: update fuzzer

>>> On 26.01.17 at 13:02, wrote: > On 26/01/17 11:28, Jan Beulich wrote: > On 25.01.17 at 16:44, wrote: >>> --- a/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c >>> +++ b/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c >>> @@ -16,26 +16,75 @@ >>> >>> #include

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

>>> On 19.01.17 at 18:29, wrote: > +static int __init pvh_setup_acpi_madt(struct domain *d, paddr_t *addr) > +{ > +struct acpi_table_madt *madt; > +struct acpi_table_header *table; > +struct acpi_madt_io_apic *io_apic; > +struct acpi_madt_local_apic *local_apic; > +struct acpi_

[Xen-devel] [xen-unstable-smoke test] 104709: regressions - trouble: blocked/broken/fail

flight 104709 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104709/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf

Re: [Xen-devel] [PATCH v8 1/8] public / x86: Introduce __HYPERCALL_dm_op...

On 01/26/2017 08:55 AM, Paul Durrant wrote: >> -Original Message- >> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] >> Sent: 26 January 2017 13:26 >> To: Paul Durrant ; xen-de...@lists.xenproject.org >> Cc: Ian Jackson ; Jennifer Herbert >> ; Jan Beulich >> Subject: Re: [Xen-dev

Re: [Xen-devel] [PATCH v8 1/8] public / x86: Introduce __HYPERCALL_dm_op...

> -Original Message- > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: 26 January 2017 13:26 > To: Paul Durrant ; xen-de...@lists.xenproject.org > Cc: Ian Jackson ; Jennifer Herbert > ; Jan Beulich > Subject: Re: [Xen-devel] [PATCH v8 1/8] public / x86: Introduce > __HYPE

Re: [Xen-devel] [PATCH v5 8/9] xen/x86: Setup PVHv2 Dom0 CPUs

>>> On 19.01.17 at 18:29, wrote: > @@ -2096,6 +2097,56 @@ static int __init pvh_load_kernel(struct domain *d, > const module_t *image, > return 0; > } > > +static int __init pvh_setup_cpus(struct domain *d, paddr_t entry, > + paddr_t start_info) > +{ > +

Re: [Xen-devel] [PATCH v5 7/9] x86/PVHv2: fix dom0_max_vcpus so it's capped to 128 for PVHv2 Dom0

>>> On 19.01.17 at 18:29, wrote: > @@ -176,6 +177,8 @@ unsigned int __init dom0_max_vcpus(void) > max_vcpus = opt_dom0_max_vcpus_max; > if ( max_vcpus > MAX_VIRT_CPUS ) > max_vcpus = MAX_VIRT_CPUS; > +if ( dom0_pvh && max_vcpus > HVM_MAX_VCPUS ) > +max_vcpus = HV

Re: [Xen-devel] [PATCH v5 6/9] xen/x86: parse Dom0 kernel for PVHv2

>>> On 19.01.17 at 18:29, wrote: > @@ -1959,12 +1960,146 @@ static int __init pvh_setup_p2m(struct domain *d) > #undef MB1_PAGES > } > > +static int __init pvh_load_kernel(struct domain *d, const module_t *image, > + unsigned long image_headroom, > +

Re: [Xen-devel] [PATCH v5 5/9] x86/hvm: add vcpu parameter to guest memory copy function

>>> On 19.01.17 at 18:29, wrote: > --- a/xen/include/asm-x86/hvm/support.h > +++ b/xen/include/asm-x86/hvm/support.h > @@ -71,6 +71,8 @@ enum hvm_copy_result hvm_copy_to_guest_phys( > paddr_t paddr, void *buf, int size); > enum hvm_copy_result hvm_copy_from_guest_phys( > void *buf, padd

Re: [Xen-devel] [PATCH v8 1/8] public / x86: Introduce __HYPERCALL_dm_op...

On 01/24/2017 10:27 AM, Paul Durrant wrote: > ...as a set of hypercalls to be used by a device model. > > As stated in the new docs/designs/dm_op.markdown: > > "The aim of DMOP is to prevent a compromised device model from > compromising domains other then the one it is associated with. (And is > t

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

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

Re: [Xen-devel] [PATCH v1 2/3] x86/xen/time: setup vcpu 0 time info page

On 01/25/2017 07:26 PM, Boris Ostrovsky wrote: > On 01/25/2017 12:33 PM, Joao Martins wrote: >> In order to support pvclock vdso on xen we need to setup the time >> info page for vcpu 0 and register the page with Xen using the >> VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall >> wi

  1   2   >