Re: [Xen-devel] [PATCH 0/3] The 'null' Scheduler

On Fri, 17 Mar 2017, Dario Faggioli wrote: > Hello, > > This patch series implements what I call the 'null' scheduler. > > It's a very simple, very static scheduling posicy that always schedules the > same vCPU(s) on the same pCPU(s). That's it. > > If there are less vCPUs than pCPUs, some of

[Xen-devel] [qemu-mainline test] 106787: regressions - FAIL

;a=summary Not pushing. commit bedf13ecab38bcd479e9db6994ebc3b2c5c7a3ae Merge: ebedf0f 7bc4f08 Author: Peter Maydell <peter.mayd...@linaro.org> Date: Mon Mar 20 10:05:45 2017 + Merge remote-tracking branch 'remotes/kraxel/tags/pull-fixes-20170320-1

Re: [Xen-devel] [PATCH 17/18] xen/arm: Prevent slipping hypervisor SError to guest

On Mon, 13 Mar 2017, Wei Chen wrote: > If there is a pending SError while we're returning from trap. If the > SError handle option is "DIVERSE", we have to prevent slipping this > hypervisor SError to guest. So we have to use the dsb/isb to guarantee > that the pending hypervisor SError would be

Re: [Xen-devel] [PATCH 3/3] tools: sched: add support for 'null' scheduler

On Fri, 17 Mar 2017, Dario Faggioli wrote: > It being very very basic, also means this scheduler does > not need much support at the tools level (for now). > > Basically, just the definition of the symbol of the > scheduler itself and a couple of stubs. > > Signed-off-by: Dario Faggioli

Re: [Xen-devel] [PATCH 1/3] xen: sched: introduce the 'null' semi-static scheduler

On Fri, 17 Mar 2017, Dario Faggioli wrote: > In cases where one is absolutely sure that there will be > less vCPUs than pCPUs, having to pay the cose, mostly in > terms of overhead, of an advanced scheduler may be not > desirable. > > The simple scheduler implemented here could be a solution. >

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

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

Re: [Xen-devel] [PATCH 14/18] xen/arm: Unmask the Abort/SError bit in the exception entries

On Mon, 13 Mar 2017, Wei Chen wrote: > Currently, we masked the Abort/SError bit in Xen exception entries. > So Xen could not capture any Abort/SError while it's running. > Now, Xen has the ability to handle the Abort/SError, we should unmask > the Abort/SError bit by default to let Xen capture

Re: [Xen-devel] [PATCH 15/18] xen/arm: Introduce a helper to synchronize SError

On Mon, 20 Mar 2017, Stefano Stabellini wrote: > On Mon, 13 Mar 2017, Wei Chen wrote: > > We may have to isolate the SError between the context switch of > > 2 vCPUs or may have to prevent slipping hypervisor SError to guest. > > I thought the problem is not the risk of slipping hypervisor

Re: [Xen-devel] [PATCH 0/2] xen/arm32: Use alternative to skip the check of pending serrors

On Thu, 16 Mar 2017, Julien Grall wrote: > Hi, > > On 03/16/2017 09:53 AM, Wei Chen wrote: > > We have provided an option to administrator to determine how to > > handle the SErrors. In order to avoid add overhead to check the > > option at every trap, we want to use the alternative to skip > >

Re: [Xen-devel] [PATCH v6] xen: Allow a default compiled-in command line using Kconfig

On Tue, 21 Mar 2017, Zhongze Liu wrote: > Added 2 new config entries in common/Kconfig: > CMDLINE and CMDLINE_OVERRIDE > Modifed common/kernel.c:cmdline_parse(). > > The 2 new entries enable an embedded command line to be compiled > in the hypervisor. CMDLINE depends on EXPERT = "y", and

Re: [Xen-devel] [PATCH 2/3] xen: sched_null: support for hard affinity

On Fri, 17 Mar 2017, Dario Faggioli wrote: > As a (rudimental) way of directing and affecting the > placement logic implemented by the scheduler, support > vCPU hard affinity. > > Basically, a vCPU will now be assigned only to a pCPU > that is part of its own hard affinity. If such pCPU(s) > is

[Xen-devel] [linux-linus test] 106777: regressions - trouble: blocked/broken/fail/pass

flight 106777 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/106777/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254

Re: [Xen-devel] [PATCH v2 1/2] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP

>>> On 17.03.17 at 19:29, wrote: > On 17/03/17 19:19, Dario Faggioli wrote: >> Within context_saved(), we call the context_saved hook, >> and we use VCPU2OP() to determine from what scheduler. >> VCPU2OP uses DOM2OP, which uses d->cpupool, which is >> NULL when d is the idle

Re: [Xen-devel] [PATCH 1/2] xen/arm32: Introduce alternative runtime patching

Hi Konrad, On 2017/3/17 22:34, Konrad Rzeszutek Wilk wrote: > On Thu, Mar 16, 2017 at 05:53:38PM +0800, Wei Chen wrote: >> This patch is based on the implementation of ARM64, it introduces >> alternative runtime patching to ARM32. This allows to patch assembly >> instruction at runtime to either

Re: [Xen-devel] question: xen/qemu - mmio mapping issues for device pass-through

>>> On 20.03.17 at 02:58, wrote: > On March 16, 2017 11:32 PM, Jan Beulich wrote: > On 16.03.17 at 15:21, wrote: >>> On March 16, 2017 10:06 PM, Jan Beulich wrote: >>> On 16.03.17 at 14:55, wrote: > I try to pass-through a

[Xen-devel] [PATCH 1/2] xenstore: set correct error code when violating quota

When the number of permitted xenstore entries for a domain is being exceeded the operation trying to create a new entry is denied. Unfortunately errno isn't being set in this case so the error code returned to the client is undefined. Set errno to ENOSPC in this case. Signed-off-by: Juergen

[Xen-devel] [PATCH 0/2] xensore: fixing two bugs

Two small patches to fix bugs: one error path correction (setting correct error code for caller) and add some missing checks for allocation failures. Juergen Gross (2): xenstore: set correct error code when violating quota xenstore: add missing checks for allocation failure

[Xen-devel] [PATCH 2/2] xenstore: add missing checks for allocation failure

Add a missing allocation failure checks. Signed-off-by: Juergen Gross --- tools/xenstore/xenstored_core.c | 12 1 file changed, 12 insertions(+) diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c index ed80345..fe11ff2 100644 ---

[Xen-devel] [libvirt test] 106780: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 106780 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/106780/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-xsm 3 host-install(3) broken in 106769 pass in 106780

Re: [Xen-devel] [PATCH 08/18] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

Hi Stefano, On 2017/3/18 1:21, Stefano Stabellini wrote: > On Fri, 17 Mar 2017, Wei Chen wrote: >> Hi Stefano, >> On 2017/3/17 7:30, Stefano Stabellini wrote: >>> On Mon, 13 Mar 2017, Wei Chen wrote: In the later patches of this series, we want to use the alternative patching framework

[Xen-devel] [PATCH v18] xen/sndif: Add sound-device ABI

From: Oleksandr Andrushchenko Add ABI for the two halves of a para-virtualized sound driver to communicate with each other. The ABI allows implementing audio playback and capture as well as volume control and possibility to mute/unmute audio sources. Note:

[Xen-devel] [PATCH v18] xen/sndif: Add sound-device ABI

From: Oleksandr Andrushchenko Hi, all! Please find the next version of the ABI for the PV sound after addressing review comments. Thank you, Oleksandr Andrushchenko Oleksandr Grytsov Oleksandr Andrushchenko (1): xen/sndif: Add sound-device ABI

Re: [Xen-devel] [PATCH v3] x86/time: Don't use virtual TSC if host and guest frequencies are equal

>>> On 17.03.17 at 19:15, wrote: > Commit 82713ec8d2 ("x86: use native RDTSC(P) execution when guest and > host frequencies are the same") left out optimization for PV guests > when host and guest run at the same frequency. > > For such a case we should be able not to

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

On 03/20/2017 06:54 PM, Jan Beulich wrote: On 20.03.17 at 17:48, wrote: >> On 03/20/2017 06:40 PM, Jan Beulich wrote: >> On 20.03.17 at 17:16, wrote: On 03/20/2017 06:14 PM, Razvan Cojocaru wrote: > In any case, back when

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

flight 106784 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/106784/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 3 host-install(3)broken REGR. vs. 106777

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

flight 106791 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/106791/ 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 build-arm64-pvops 5

Re: [Xen-devel] [PATCH 18/18] xen/arm: Handle guest external abort as guest SError

On Mon, 13 Mar 2017, Wei Chen wrote: > The guest generated external data/instruction aborts can be treated > as guest SErrors. We already have a handler to handle the SErrors, > so we can reuse this handler to handle guest external aborts. > > Signed-off-by: Wei Chen

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

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

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

On Mon, Mar 20, 2017 at 2:20 PM, Razvan Cojocaru wrote: > On 03/20/2017 06:54 PM, Jan Beulich wrote: > On 20.03.17 at 17:48, wrote: > >> On 03/20/2017 06:40 PM, Jan Beulich wrote: > >> On 20.03.17 at 17:16,

Re: [Xen-devel] [PATCH 15/18] xen/arm: Introduce a helper to synchronize SError

On Mon, 13 Mar 2017, Wei Chen wrote: > We may have to isolate the SError between the context switch of > 2 vCPUs or may have to prevent slipping hypervisor SError to guest. I thought the problem is not the risk of slipping hypervisor SErrors to guest, but the risk of slipping previous guest

Re: [Xen-devel] [PATCH 16/18] xen/arm: Isolate the SError between the context switch of 2 vCPUs

On Mon, 13 Mar 2017, Wei Chen wrote: > If there is a pending SError while we are doing context switch, if the > SError handle option is "FORWARD", We have to guranatee this serror to > be caught by current vCPU, otherwise it will be caught by next vCPU and > be forwarded to this wrong vCPU. > >

Re: [Xen-devel] Supporting systems with large E820 maps

On 20/03/17 20:03, Alex Thorlton wrote: > Hey everyone, > > Recently, I've been working with Boris Ostrovsky to get Xen running on > some of our larger systems, and we've run into a few problems with the > amount of space that Xen sets aside for the E820 map. > > The first problem that I hit was

Re: [Xen-devel] [RFC PATCH 00/23] xen/vIOMMU: Add vIOMMU support with irq remapping fucntion on Intel platform

On 2017年03月21日 10:28, Lan Tianyu wrote: > On 2017年03月20日 22:23, Roger Pau Monné wrote: >> Thanks! So you add all this vIOMMU code, but the maximum number of allowed >> vCPUs for HVM guests is still limited to 128 (HVM_MAX_VCPUS is not touched). >> Is >> there any missing pieces in order to bump

[Xen-devel] ARM: SMMUv3 support

Hi, Is there any effort put by anyone to get SMMUv3 support in Xen for ARM64?. Would be glad to know. Regards Vijay ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 00/23] xen/vIOMMU: Add vIOMMU support with irq remapping fucntion on Intel platform

On 2017年03月20日 22:23, Roger Pau Monné wrote: > Thanks! So you add all this vIOMMU code, but the maximum number of allowed > vCPUs for HVM guests is still limited to 128 (HVM_MAX_VCPUS is not touched). > Is > there any missing pieces in order to bump this? To increase vcpu number, we need to

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

flight 106793 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/106793/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 106774

[Xen-devel] [PATCH v9 2/5] x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to an ioreq server.

A new DMOP - XEN_DMOP_map_mem_type_to_ioreq_server, is added to let one ioreq server claim/disclaim its responsibility for the handling of guest pages with p2m type p2m_ioreq_server. Users of this DMOP can specify which kind of operation is supposed to be emulated in a parameter named flags.

[Xen-devel] [PATCH v9 5/5] x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

After an ioreq server has unmapped, the remaining p2m_ioreq_server entries need to be reset back to p2m_ram_rw. This patch does this synchronously by iterating the p2m table. The synchronous resetting is necessary because we need to guarantee the p2m table is clean before another ioreq server is

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

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

Re: [Xen-devel] [PATCH 2/2] configure: use pkg-config for obtaining xen version

On 17/03/17 19:33, Stefano Stabellini wrote: > On Fri, 17 Mar 2017, Juergen Gross wrote: >> On 16/03/17 21:20, Stefano Stabellini wrote: >>> On Thu, 16 Mar 2017, Juergen Gross wrote: Instead of trying to guess the Xen version to use by compiling various test programs first just ask the

[Xen-devel] Supporting systems with large E820 maps

Hey everyone, Recently, I've been working with Boris Ostrovsky to get Xen running on some of our larger systems, and we've run into a few problems with the amount of space that Xen sets aside for the E820 map. The first problem that I hit was that E820MAX is far too small, at 128 entries, for

[Xen-devel] [PATCH v4] altp2m: Allow specifying external-only use-case

Currently setting altp2mhvm=1 in the domain configuration allows access to the altp2m interface for both in-guest and external privileged tools. This poses a problem for use-cases where only external access should be allowed, requiring the user to compile Xen with XSM enabled to be able to

Re: [Xen-devel] [RFC] xen/pvh: detect PVH after kexec

On 03/20/2017 02:20 PM, Vitaly Kuznetsov wrote: > PVH guests after kexec boot like normal HVM guests and we're not entering > xen_prepare_pvh() Is it not? Aren't we going via xen_hvm_shutdown() and then SHUTDOWN_soft_reset which would restart at the same entry point as regular boot? -boris >

[Xen-devel] [PATCH v9 4/5] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.

After an ioreq server has unmapped, the remaining p2m_ioreq_server entries need to be reset back to p2m_ram_rw. This patch does this asynchronously with the current p2m_change_entry_type_global() interface. This patch also disallows live migration, when there's still any outstanding

[Xen-devel] [PATCH v9 3/5] x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server pages.

In ept_handle_violation(), write violations are also treated as read violations. And when a VM is accessing a write-protected address with read-modify-write instructions, the read emulation process is triggered first. For p2m_ioreq_server pages, current ioreq server only forwards the write

[Xen-devel] [PATCH v9 0/5] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.

XenGT leverages ioreq server to track and forward the accesses to GPU I/O resources, e.g. the PPGTT(per-process graphic translation tables). Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges to be emulated. To select an ioreq server, the rangeset is searched to see if the

[Xen-devel] [PATCH v9 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

Routine hvmemul_do_io() may need to peek the p2m type of a gfn to select the ioreq server. For example, operations on gfns with p2m_ioreq_server type will be delivered to a corresponding ioreq server, and this requires that the p2m type not be switched back to p2m_ram_rw during the emulation

Re: [Xen-devel] [PATCH 02/18] xen/arm: Restore HCR_EL2 register

On Thu, 16 Mar 2017, Julien Grall wrote: > Hi Stefano > > On 03/16/2017 10:33 PM, Stefano Stabellini wrote: > > On Wed, 15 Mar 2017, Julien Grall wrote: > > > Hi Wei, > > > > > > On 15/03/17 08:34, Wei Chen wrote: > > > > On 2017/3/15 8:25, Stefano Stabellini wrote: > > > > > On Mon, 13 Mar

Re: [Xen-devel] [PATCH 04/11] Introduce cirros-separate-kernel-pv test

On Sun, 19 Mar 2017, Géza Gémes wrote: > This test is the cirros equivalent of the bussybox-pv test > > Signed-off-by: Géza Gémes > --- > tests/cirros-separate-kernel-pv | 28 > tests/series| 1 + > 2 files changed, 29

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

flight 106788 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/106788/ 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. 59254

Re: [Xen-devel] [PATCH 02/11] Fix lopartsetup parsing of fdisk output

On Sun, 19 Mar 2017, Géza Gémes wrote: > Change lopartsetup in order to handle partitions, which have the > boot flag enabled. > > Signed-off-by: Géza Gémes Reviewed-by: Stefano Stabellini > --- > scripts/lopartsetup | 6 +- > 1 file

Re: [Xen-devel] [PATCH 03/11] Introduce cirros tests

On Sun, 19 Mar 2017, Géza Gémes wrote: > Add support for using cirros images in raisin tests > > Signed-off-by: Géza Gémes > --- > configs/config-cirros | 44 ++ > defconfig | 2 + > lib/common-tests.sh | 102 >

Re: [Xen-devel] [raisin][PATCH 00/11] pygrub fix + cirros tests

Thanks for the patches! :-) I committed patch #2. Please resend the rest of the series addressing the comments. I didn't reply to each patch, but the cirros tests look good except for the few comments regarding the way they interact with the common functions. Cheers, Stefano On Sun, 19 Mar

Re: [Xen-devel] [PATCH v8 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

On 3/21/2017 1:03 AM, Jan Beulich wrote: On 18.03.17 at 11:53, wrote: --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla, (npfec.write_access &&

Re: [Xen-devel] question: xen/qemu - mmio mapping issues for device pass-through

On March 20, 2017 3:35 PM, Jan Beulich wrote: On 20.03.17 at 02:58, wrote: >> On March 16, 2017 11:32 PM, Jan Beulich wrote: >> On 16.03.17 at 15:21, wrote: On March 16, 2017 10:06 PM, Jan Beulich wrote: On 16.03.17 at 14:55,

Re: [Xen-devel] [PATCH v8 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

On 3/21/2017 9:18 AM, Yu Zhang wrote: On 3/21/2017 1:03 AM, Jan Beulich wrote: On 18.03.17 at 11:53, wrote: --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,

Re: [Xen-devel] [PATCH 01/11] Fix installation of python libs

On Sun, 19 Mar 2017, Géza Gémes wrote: > Change deb package build in order to symlink the files installed > to site-packages to dist-packages to have them inluded in the > default PYTHONPATH > > Signed-off-by: Géza Gémes > --- > scripts/mkdeb | 9 + > 1 file

Re: [Xen-devel] [PATCH 11/11] Enable cirros tests in the default config

On Sun, 19 Mar 2017, Géza Gémes wrote: > The existing cirros tests are enabled, with the following > exceptions: > > cirros-minios-stubdom-hvm and cirros-minios-stubdom-pvhvm are > skipped as raisin does not install the stubdom > > Signed-off-by: Géza Gémes Reviewed-by:

Re: [Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

On 2017年03月20日 19:38, Paolo Bonzini wrote: > Fair enough, though I'd be worried about increasing the attack surface > of the hypervisor. For KVM, for example, IOMMU emulation requires using > the "split irqchip" feature to move the PIC and IOAPIC out of the kernel > and back to QEMU. Yes, just

Re: [Xen-devel] [PATCH] x86/monitor: add support for descriptor access events

On Fri, 17 Mar 2017 05:03:44 -0600 "Jan Beulich" wrote: > >>> On 10.03.17 at 16:50, wrote: > > --- a/xen/arch/x86/hvm/hvm.c > > +++ b/xen/arch/x86/hvm/hvm.c > > @@ -3645,6 +3645,41 @@ gp_fault: > > return X86EMUL_EXCEPTION; > > } > > > > +int

Re: [Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

On 20/03/2017 03:40, Lan Tianyu wrote: >>> Xen only supports emulated I440 and so we enable vIOMMU with emulated >>> I440 chipset. This works on Linux and Windows guest. >> Any plans to change this? Why is Xen not able to use Q35 with Intel >> IOMMU, with only special hooks for interrupt

Re: [Xen-devel] [PATCH v10 5/6] passthrough/io: don't migrate pirq when it is delivered through VT-d PI

On Mon, Mar 20, 2017 at 04:26:10AM -0600, Jan Beulich wrote: On 20.03.17 at 03:38, wrote: >> On Mon, Mar 20, 2017 at 03:18:18AM -0600, Jan Beulich wrote: >> On 20.03.17 at 02:59, wrote: On Fri, Mar 17, 2017 at 04:43:08AM -0600, Jan Beulich

Re: [Xen-devel] [PATCH 5/7] x86/viridian: add warnings for unimplemented hypercalls and MSRs

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 March 2017 12:22 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH 5/7] x86/viridian: add warnings for

Re: [Xen-devel] [PATCH v2 01/12] xen/mce: switch bool_t/1/0 to bool/true/false

>>> On 17.03.17 at 07:46, wrote: > Signed-off-by: Haozhong Zhang Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 02/12] x86/mce_intel: refine messages of MCA capabilities

>>> On 17.03.17 at 07:46, wrote: > ... to only print available ones. Suggested-by: Jan Beulich > Signed-off-by: Haozhong Zhang Reviewed-by: Jan Beulich

Re: [Xen-devel] [PATCH 3/7] x86/viridian: don't put Xen version information in CPUID leaf 2

>>> On 20.03.17 at 12:57, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 20 March 2017 11:42 >> >>> On 17.03.17 at 10:57, wrote: >> > So, clearly putting Xen hypervisor version information in that leaf is >> > spurious, but we

Re: [Xen-devel] [PATCH 5/7] x86/viridian: add warnings for unimplemented hypercalls and MSRs

>>> On 17.03.17 at 10:57, wrote: > The warnings are rate limited so a malicious guest cannot use them to > as a DoS. In fact they're debug-build-only ones. Did you perhaps mean gprintk()? > @@ -534,6 +592,10 @@ int wrmsr_viridian_regs(uint32_t idx, uint64_t val) >

Re: [Xen-devel] [PATCH 7/7] x86/viridian: implement the crash MSRs

>>> On 17.03.17 at 10:57, wrote: > @@ -234,6 +247,10 @@ void cpuid_viridian_leaves(const struct vcpu *v, > uint32_t leaf, > > res->a = u.lo; > res->b = u.hi; > + > +if ( viridian_feature_mask(d) & HVMPV_crash_ctl ) > +res->d =

Re: [Xen-devel] [PATCH v10 5/6] passthrough/io: don't migrate pirq when it is delivered through VT-d PI

>>> On 20.03.17 at 06:22, wrote: > On Mon, Mar 20, 2017 at 04:26:10AM -0600, Jan Beulich wrote: > On 20.03.17 at 03:38, wrote: >>> On Mon, Mar 20, 2017 at 03:18:18AM -0600, Jan Beulich wrote: >>> On 20.03.17 at 02:59, wrote:

Re: [Xen-devel] [PATCH 3/7] x86/viridian: don't put Xen version information in CPUID leaf 2

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 March 2017 12:03 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: RE: [PATCH 3/7] x86/viridian: don't put Xen version

Re: [Xen-devel] [PATCH v2 03/12] xen/mce: add blank lines between non-fall-through switch case blocks

>>> On 17.03.17 at 07:46, wrote: > Signed-off-by: Haozhong Zhang Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/7] x86/viridian: don't put Xen version information in CPUID leaf 2

>>> On 20.03.17 at 14:08, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 20 March 2017 12:03 >> >>> On 20.03.17 at 12:57, wrote: >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> Sent: 20 March 2017 11:42 >> >> >>> On

Re: [Xen-devel] [PATCH 1/7] x86/viridian: update to version 5.0a of the specification

>>> On 20.03.17 at 12:43, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 20 March 2017 11:27 >> To: Paul Durrant >> Cc: Andrew Cooper ; Wei Liu >> ;

Re: [Xen-devel] [PATCH 3/7] x86/viridian: don't put Xen version information in CPUID leaf 2

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 March 2017 11:42 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH 3/7] x86/viridian: don't put Xen version

Re: [Xen-devel] [PATCH v2 14/27] ARM: vGICv3: introduce basic ITS emulation bits

On Thu, Mar 16, 2017 at 9:55 PM, Shanker Donthineni wrote: > Hi Andre, > > > On 03/16/2017 06:20 AM, Andre Przywara wrote: >> Create a new file to hold the emulation code for the ITS widget. >> For now we emulate the memory mapped ITS registers and provide a stub >> to

Re: [Xen-devel] [PATCH 6/7] x86/viridian: make the threshold for HvNotifyLongSpinWait tunable

>>> On 17.03.17 at 10:57, wrote: > --- a/xen/arch/x86/hvm/viridian.c > +++ b/xen/arch/x86/hvm/viridian.c > @@ -22,6 +22,12 @@ > #include > #include > > +#define VIRIDIAN_SPINLOCK_RETRY_COUNT_DEFAULT 2047 > + > +static int __read_mostly viridian_spinlock_retry_count;

[Xen-devel] [PATCH v2 07/10] x86: assembly, annotate aliases

_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS, and SYM_FUNC_END_ALIAS. This will make the tools generating the debuginfo happy.

[Xen-devel] [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions

Somewhere END was used to end a function, elsewhere, nothing was used. So unify it and mark them all by SYM_FUNC_END. Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc:

[Xen-devel] [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

This is a start of series to cleanup macros used for starting functions, data, globals etc. across x86. When we have all this sorted out, this will help to inject DWARF unwinding info by objtool later. The goal is forcing SYM_FUNC_START to emit .cfi_startproc and SYM_FUNC_END to emit

[Xen-devel] [PATCH v2 01/10] linkage: new macros for assembler symbols

Introduce new C macros for annotations of functions and data in assembly. There is a long-term mess in macros like ENTRY, END, ENDPROC and similar. They are used in different manners and sometimes incorrectly. So introduce macros with clear use to annotate assembly as follows: a) Support macros

Re: [Xen-devel] [PATCH 6/7] x86/viridian: make the threshold for HvNotifyLongSpinWait tunable

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 March 2017 12:26 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH 6/7] x86/viridian: make the threshold for >

Re: [Xen-devel] [PATCH 4/7] x86/viridian: get rid of the magic numbers in CPUID leaves 1 and 2

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 March 2017 12:15 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH 4/7] x86/viridian: get rid of the magic

Re: [Xen-devel] [PATCH v10 5/6] passthrough/io: don't migrate pirq when it is delivered through VT-d PI

On Mon, Mar 20, 2017 at 06:50:37AM -0600, Jan Beulich wrote: On 20.03.17 at 06:22, wrote: >> On Mon, Mar 20, 2017 at 04:26:10AM -0600, Jan Beulich wrote: >> On 20.03.17 at 03:38, wrote: On Mon, Mar 20, 2017 at 03:18:18AM -0600, Jan Beulich

Re: [Xen-devel] [PATCH v10 5/6] passthrough/io: don't migrate pirq when it is delivered through VT-d PI

On Fri, Mar 17, 2017 at 04:43:08AM -0600, Jan Beulich wrote: On 15.03.17 at 06:11, wrote: >> @@ -441,6 +442,15 @@ int pt_irq_create_bind( >> >> dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode); >> pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id;

Re: [Xen-devel] [PATCH v2 8/9] x86/pagewalk: Improve the logic behind setting access and dirty bits

>>> On 16.03.17 at 17:31, wrote: > @@ -413,24 +417,33 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain > *p2m, > * success. Although the PRMs say higher-level _PAGE_ACCESSED bits > * get set whenever a lower-level PT is used, at least some hardware >

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

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

Re: [Xen-devel] [PATCH] dm_op: Add xendevicemodel_modified_memory_bulk.

>>> On 16.03.17 at 15:44, wrote: > --- a/xen/arch/x86/hvm/dm.c > +++ b/xen/arch/x86/hvm/dm.c > @@ -119,56 +119,96 @@ static int set_isa_irq_level(struct domain *d, uint8_t > isa_irq, > } > > static int modified_memory(struct domain *d, > -

Re: [Xen-devel] [PATCH 2/7] x86/viridian: fix xen-hvmcrash when vp_assist page is present

>>> On 17.03.17 at 10:57, wrote: > @@ -288,6 +304,14 @@ static void initialize_vp_assist(struct vcpu *v) > * enlightenment. > */ > > +if ( v->arch.hvm_vcpu.viridian.vp_assist.va ) > +{ > +if ( v->arch.hvm_vcpu.viridian.vp_assist.gmfn == gmfn

Re: [Xen-devel] [PATCH 1/7] x86/viridian: update to version 5.0a of the specification

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 March 2017 11:27 > To: Paul Durrant > Cc: Andrew Cooper ; Wei Liu > ; Ian Jackson ; xen- >

Re: [Xen-devel] [PATCH 2/7] x86/viridian: fix xen-hvmcrash when vp_assist page is present

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 March 2017 11:36 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH 2/7] x86/viridian: fix xen-hvmcrash when

Re: [Xen-devel] [PATCH v2] x86/emul: Poision the stubs with debug traps

>>> On 20.03.17 at 11:58, wrote: > ...rather than leaving fragments of old instructions in place. This reduces > the chances of something going further-wrong (as the debug trap will be > caught > and terminate the guest) in a cascade-failure where we end up executing

Re: [Xen-devel] [PATCH] AMD-Vi: allocate root table on demand

>>> On 20.03.17 at 12:49, wrote: >> @@ -648,6 +647,13 @@ int amd_iommu_map_page(struct domain *d, >> >> spin_lock(>arch.mapping_lock); >> >> +rc = amd_iommu_alloc_root(hd); >> +if ( rc ) >> +{ >> +spin_unlock(>arch.mapping_lock); >> +

Re: [Xen-devel] [PATCH 4/7] x86/viridian: get rid of the magic numbers in CPUID leaves 1 and 2

>>> On 17.03.17 at 10:57, wrote: > --- a/xen/arch/x86/hvm/viridian.c > +++ b/xen/arch/x86/hvm/viridian.c > @@ -119,14 +119,16 @@ void cpuid_viridian_leaves(const struct vcpu *v, > uint32_t leaf, > switch ( leaf ) > { > case 0: > +/* See section

Re: [Xen-devel] [PATCH 7/7] x86/viridian: implement the crash MSRs

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 March 2017 12:38 > To: Paul Durrant > Cc: Andrew Cooper ; Wei Liu > ; Ian Jackson ; xen- >

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

From: Oleksandr Andrushchenko This is the ABI for the two halves of a para-virtualized display driver. This protocol aims to provide a unified protocol which fits more sophisticated use-cases than a framebuffer device can handle. At the moment basic

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

From: Oleksandr Andrushchenko This is the ABI for the two halves of a para-virtualized display driver. This protocol aims to provide a unified protocol which fits more sophisticated use-cases than a framebuffer device can handle. At the moment basic

Re: [Xen-devel] [PATCH v2 2/4] x86: split PV dom0 builder to pv/dom0_builder.c

>>> On 16.03.17 at 18:54, wrote: > @@ -154,11 +155,11 @@ static void __init parse_dom0_nodes(const char *s) > } > custom_param("dom0_nodes", parse_dom0_nodes); > > -static cpumask_t __initdata dom0_cpus; > +cpumask_t __initdata dom0_cpus; I'd prefer if this variable

[Xen-devel] [OSSTEST PATCH] cs-adjust-flight: Remove broken memoisation of queries in for_things

The memo keys failed to include many of the important inputs. CC: Roger Pau Monné Signed-off-by: Ian Jackson --- cs-adjust-flight | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/cs-adjust-flight b/cs-adjust-flight index

Re: [Xen-devel] [PATCH v2 2/9] x86/pagewalk: Use pointer syntax for pfec parameter

On 16/03/17 16:31, Andrew Cooper wrote: > It is a pointer, not an array. > > No functional change. > > Requested-by: Jan Beulich > Signed-off-by: Andrew Cooper Thank you, this has bothered me for a long time: Reviewed-by: George Dunlap

Re: [Xen-devel] [PATCH v2 5/9] x86/pagewalk: Helpers for reserved bit handling

>>> On 16.03.17 at 17:31, wrote: > Some bits are unconditionally reserved in pagetable entries, or reserved > because of alignment restrictions. Other bits are reserved because of control > register configuration. > > Introduce helpers which take an individual vcpu

  1   2   3   >