Re: [Xen-devel] [PATCH v12 15/23] x86: refactor psr: CDP: implement set value callback function.

>>> On 03.07.17 at 08:33, wrote: > On 17-06-30 06:02:32, Jan Beulich wrote: >> >>> Yi Sun 06/30/17 1:30 PM >>> >> >The input 'type' is CODE. The props->type[0] is DATA and props->type[1] is >> >CODE. >> >In the first iteration, the props->type[0] is DATA so that it does not match >> >'type' and

Re: [Xen-devel] [PATCH RFC 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0

>>> On 30.06.17 at 17:33, wrote: > On Fri, Jun 30, 2017 at 05:27:06AM -0600, Jan Beulich wrote: >> >>> Roger Pau Monne 04/24/17 1:52 PM >>> >> >--- a/xen/arch/x86/dom0_build.c >> >+++ b/xen/arch/x86/dom0_build.c >> >@@ -18,6 +18,8 @@ >> >#include >> >#include >> > >> >+#include "x86_64/mmcon

Re: [Xen-devel] [PATCH RFC 2/4] x86/dom0: prevent PVH Dom0 from mapping read-only the IO APIC area

>>> On 30.06.17 at 17:34, wrote: > On Fri, Jun 30, 2017 at 05:31:36AM -0600, Jan Beulich wrote: >> >>> Roger Pau Monne 04/24/17 1:52 PM >>> >> >This is emulated by Xen and must not be mapped into PVH Dom0 p2m. >> >> Yes, but this reminds of of the reason we permit the r/o mapping in PV >> Dom0,

[Xen-devel] [xtf test] 111350: regressions - trouble: broken/pass

flight 111350 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/111350/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-5 59 leak-check/check fail REGR. vs. 111074 test-xtf-amd64-amd64-3

[Xen-devel] [BUG] Segv in radeon drm

Not sure who this should go to, but running linux as domU under Xen triggers this bug. modprobe radeon on a linux domU wich has a "VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM]" -card passed through to it, causes a NULL dereference i

Re: [Xen-devel] [PATCH v5 10/12] x86/xen: Bypass intr mode setup in enlighten_pv system

Hi Thomas, At 07/03/2017 02:56 PM, Thomas Gleixner wrote: On Mon, 3 Jul 2017, Dou Liyang wrote: At 07/03/2017 03:18 AM, Thomas Gleixner wrote: On Fri, 30 Jun 2017, Dou Liyang wrote: xen_smp_ops overwrites smp_prepare_cpus to xen_pv_smp_prepare_cpus which initializes interrupt itself. Touchi

Re: [Xen-devel] [PATCH 00/18] x86: more bool_t to bool cleanup

>>> On 30.06.17 at 19:01, wrote: > Seeing that bool_t keeps creeping back in new patches I think the only > solution > is to get rid of bool_t once and for all, as soon as possible. I don't fully agree, and considering the flood of patches you're submitting in this area I think I finally need to

Re: [Xen-devel] [PATCH v3 07/16] xen/arm: livepatch: Redefine virt_to_mfn to support typesafe

On 06/30/2017 04:54 PM, Julien Grall wrote: The file xen/arch/arm/livepatch.c is using typesafe MFN in most of the place. The only caller to virt_to_mfn is using with _mfn(...). To avoid extra _mfn(...), re-define virt_to_mfn within xen/arch/arm/livepatch.c to handle typesafe MFN. Signed-off-by

Re: [Xen-devel] [PATCH v12 15/23] x86: refactor psr: CDP: implement set value callback function.

On 17-07-03 01:01:09, Jan Beulich wrote: > >>> On 03.07.17 at 08:33, wrote: > > On 17-06-30 06:02:32, Jan Beulich wrote: > >> >>> Yi Sun 06/30/17 1:30 PM >>> > >> >The input 'type' is CODE. The props->type[0] is DATA and props->type[1] > >> >is CODE. > >> >In the first iteration, the props->type

Re: [Xen-devel] [PATCH v5 02/12] arm/mem_access: Move PAGE_SHIFT_* macros to lib.h

Hi Jan, On 06/27/2017 02:04 PM, Jan Beulich wrote: Sergej Proskurin 06/27/17 1:52 PM >>> >> The following commits introduce a software guest page table walk >> software implementation that supports varying guest page size >> granularities. This commit moves already existing PAGE_SHIFT_(4K|6

Re: [Xen-devel] [PATCH v3 09/16] xen/arm: Move LPAE definition in a separate header

Hi Julien, On 06/30/2017 05:54 PM, Julien Grall wrote: > page.h is getting bigger. Move out every LPAE definitions in a separate > header. There is no functional changes. > > Signed-off-by: Julien Grall > Reviewed-by: Stefano Stabellini > > --- > > Cc: prosku...@sec.in.tum.de > > Changes in

Re: [Xen-devel] [PATCH v5 02/12] arm/mem_access: Move PAGE_SHIFT_* macros to lib.h

Hi Jan, On 07/03/2017 10:40 AM, Sergej Proskurin wrote: > Hi Jan, > > > On 06/27/2017 02:04 PM, Jan Beulich wrote: > Sergej Proskurin 06/27/17 1:52 PM >>> >>> The following commits introduce a software guest page table walk >>> software implementation that supports varying guest page size >>

Re: [Xen-devel] Is anyone interested in hosting the following to Design Sessions at our Summit: "Versioning ABC" and "Improvements to Continuous Integration Workflow"?

These will now be removed: I merged some of https://xendeveloperanddesignsummit2017.sched.com/event/AjGa/improvements-to-continuous-integration-workflow-doug-goldstein-star-lab

Re: [Xen-devel] [PATCH v5 02/12] arm/mem_access: Move PAGE_SHIFT_* macros to lib.h

>>> On 03.07.17 at 10:40, wrote: > On 06/27/2017 02:04 PM, Jan Beulich wrote: > Sergej Proskurin 06/27/17 1:52 PM >>> >>> The following commits introduce a software guest page table walk >>> software implementation that supports varying guest page size >>> granularities. This commit moves alr

Re: [Xen-devel] [PATCH v5 02/12] arm/mem_access: Move PAGE_SHIFT_* macros to lib.h

>>> On 03.07.17 at 11:03, wrote: > To prevent potential type width issues with ARMv7, I would reuse the > macro from xen/iommu.h at this point: > > PAGE_MASK_GRAN(sz) (~(u64)0 << PAGE_SHIFT_##sz) Seems reasonable, except - no new use of u64 please (use uint64_t instead) - it'

Re: [Xen-devel] [PATCH v12 15/23] x86: refactor psr: CDP: implement set value callback function.

>>> On 03.07.17 at 10:40, wrote: > On 17-07-03 01:01:09, Jan Beulich wrote: >> >>> On 03.07.17 at 08:33, wrote: >> > On 17-06-30 06:02:32, Jan Beulich wrote: >> >> >>> Yi Sun 06/30/17 1:30 PM >>> >> >> >The input 'type' is CODE. The props->type[0] is DATA and props->type[1] >> >> >is > CODE. >

[Xen-devel] [distros-debian-sid test] 71625: tolerable trouble: blocked/broken/fail/pass

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

[Xen-devel] [libvirt test] 111317: tolerable FAIL - PUSHED

flight 111317 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/111317/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt 6 xen-install fail in 111258 pass in 111317 test-armhf-armhf-libvirt-raw 11 guest

[Xen-devel] [xtf test] 111353: all pass - PUSHED

flight 111353 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/111353/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 0d6dddbd5a5666cb7d052688724662214a771033 baseline version: xtf 6723a66fe3e2a60793ec4f

Re: [Xen-devel] [OSSTEST PATCH v11 20/20] Introduce flight for stable branches of OpenStack

Anthony PERARD writes ("Re: [OSSTEST PATCH v11 20/20] Introduce flight for stable branches of OpenStack"): > On Fri, Jun 23, 2017 at 06:00:29PM +0100, Ian Jackson wrote: > > Anthony PERARD writes ("[OSSTEST PATCH v11 20/20] Introduce flight for > > stable branches of OpenStack"): > > So perhaps t

[Xen-devel] RT-Xen on ARM

Dear Meng Xu, We are going to evaluate an RTDS scheduler on ARM. Basically I'm going to repeat use-cases described in https://www.cis.upenn.edu/~linhphan/papers/emsoft14-rt-xen.pdf in some amount. Do you have any recommendations or suggestions? BTW, even following https://xenbits.xen.org/

[Xen-devel] [PATCH v6 04/12] x86/apic: Move logical APIC ID away from apic_bsp_setup()

apic_bsp_setup() sets and returns logical APIC ID for initializing cpu0_logical_apicid in SMP-capable system. The id has nothing to do with the initialization of local APIC and I/O APIC. And apic_bsp_setup() should be called for interrupt mode setup intently. Move the id setup into a separate hel

[Xen-devel] [PATCH v6 06/12] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

Calling native_smp_prepare_cpus() to prepare for SMP bootup, does some sanity checking, enables APIC mode and disables SMP feature. Now, APIC mode setup has been unified to apic_intr_mode_init(), some sanity checks are redundant and need to be cleanup. Mark the apic_intr_mode extern to refine the

[Xen-devel] [PATCH v6 02/12] x86/apic: Prepare for unifying the interrupt delivery modes setup

There are three positions for initializing the interrupt delivery modes: 1) In IRQ initial function, may setup the through-local-APIC virtual wire mode. 2) In an SMP-capable system, will try to switch to symmetric I/O model when preparing the cpus in native_smp_prepare_cpus(). 3) In UP sys

[Xen-devel] [PATCH v6 01/12] x86/apic: Construct a selector for the interrupt delivery mode

Now, there are many switches in kernel which are used to determine the final interrupt delivery mode, as shown below: 1) kconfig: CONFIG_X86_64; CONFIG_X86_LOCAL_APIC; CONFIG_x86_IO_APIC 2) kernel option: disable_apic; skip_ioapic_setup 3) CPU Capability: boot_cpu_has(X86_FEATURE_APIC) 4) MP ta

[Xen-devel] [PATCH v6 00/12] Unify the interrupt delivery mode and do its setup in advance

[Background] MP specification defines three different interrupt delivery modes as follows: 1. PIC Mode 2. Virtual Wire Mode 3. Symmetric I/O Mode They will be setup in the different periods of booting time: 1. *PIC Mode*, the default interrupt delivery modes, will be set first. 2. *Virtual

[Xen-devel] [PATCH v6 05/12] x86/apic: Unify interrupt mode setup for SMP-capable system

In the SMP-capable system, enable and setup the interrupt delivery mode in native_smp_prepare_cpus(). This design mixs the APIC and SMP together, it has highly coupling. Make the initialization of interrupt mode independent, Unify and refine it to apic_intr_mode_init() for SMP-capable system. Si

[Xen-devel] [PATCH v6 08/12] x86/ioapic: Refactor the delay logic in timer_irq_works()

Kernel use timer_irq_works() to detects the timer IRQs. It calls mdelay(10) to delay ten ticks and check whether the timer IRQ work or not. The mdelay() depends on the loops_per_jiffy which is set up in calibrate_delay(). Current kernel defaults the IRQ 0 is available when it calibrates delay. But

[Xen-devel] [PATCH v6 10/12] x86/xen: Bypass intr mode setup in enlighten_pv system

XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus() initializes interrupts in the XEN PV specific way and does not invoke native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is not invoked either. The invocation of x86_init.intr_mode_init() will be moved from native_s

[Xen-devel] [PATCH v6 09/12] x86/init: add intr_mode_init to x86_init_ops

X86 and XEN initialize interrupt delivery mode in different way. Ordinary conditional function calls will make the code mess. Add an unconditional x86_init_ops function which defaults to the standard function and can be overridden by the early platform code. Signed-off-by: Dou Liyang --- arch/

[Xen-devel] [PATCH v6 12/12] x86/apic: Remove the init_bsp_APIC()

The init_bsp_APIC() which works for the virtual wire mode is used in ISA irq initialization at the booting time. Currently, enable and setup the interrupt mode has been unified and advanced just behind the timer IRQ setup. Kernel switches to the final interrupt delivery mode directly. So init_bsp_

[Xen-devel] [PATCH v6 11/12] x86/time: Initialize interrupt mode behind timer init

In start_kernel(), firstly, it works on the default interrupy mode, then switch to the final mode. Normally, Booting with BIOS reset is OK. But, At dump-capture kernel, it boot up without BIOS reset, default mode may not be compatible with the actual registers, that causes the delivery interrupt t

[Xen-devel] [PATCH v6 03/12] x86/apic: Split local APIC timer setup from the APIC setup

apic_bsp_setup() sets up the local APIC, I/O APIC and APIC timer. The local APIC and I/O APIC setup belongs to interrupt delivery mode setup. Setting up the local APIC timer for booting CPU is another job and has nothing to do with interrupt delivery mode setup. Split local APIC timer setup from

[Xen-devel] [PATCH v6 07/12] x86/apic: Unify interrupt mode setup for UP system

In UniProcessor kernel with UP_LATE_INIT=y, it enables and setups interrupt delivery mode in up_late_init(). Unify it to apic_intr_mode_init(), remove APIC_init_uniprocessor(). Signed-off-by: Dou Liyang --- arch/x86/include/asm/apic.h | 1 - arch/x86/kernel/apic/apic.c | 47 ++-

Re: [Xen-devel] [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes

Hi, On 01/07/17 10:16, Zhongze Liu wrote: On the ARM side, we are missing BUFFERABLE and WRITEALLOC. I don't know how they map to these tags, which comes from the x86 world. Maybe we should just add them separately as ARM only, like: /* bufferable, ARM only */ #define XEN_DOMCTL_MEMATTRS_BU

Re: [Xen-devel] [PATCH v5 06/18] xen/pvcalls: handle commands from the frontend

On 22/06/17 21:14, Stefano Stabellini wrote: > When the other end notifies us that there are commands to be read > (pvcalls_back_event), wake up the backend thread to parse the command. > > The command ring works like most other Xen rings, so use the usual > ring macros to read and write to it. Th

Re: [Xen-devel] [PATCH] x86: xen: remove unnecessary variable in xen_foreach_remap_area()

On 24/06/17 00:01, Gustavo A. R. Silva wrote: > Remove unnecessary variable mfn in function xen_foreach_remap_area() and, > refactor the code. > > Variable mfn at line 518:mfn = xen_remap_buf.mfns[i]; > is only being used to store a value to be passed as > an argument to the xen_update_mem_tables(

Re: [Xen-devel] [PATCH v2] x86/xen: allow userspace access during hypercalls

On 26/06/17 14:49, Marek Marczykowski-Górecki wrote: > Userspace application can do a hypercall through /dev/xen/privcmd, and > some for some hypercalls argument is a pointers to user-provided > structure. When SMAP is supported and enabled, hypervisor can't access. > So, lets allow it. > > The sa

[Xen-devel] race in vif-common.sh

Hello in /etc/xen/scripts/vif-common.sh there is a function handle_iptable. At its start there is a check for a working iptables implementation. This check is outside the iptables lock section (claim_lock "iptables") and even if it is only a read-only operation the underlying iptables operatio

[Xen-devel] race in vif-common.sh

Hello in /etc/xen/scripts/vif-common.sh there is a function handle_iptable. At its start there is a check for a working iptables implementation. This check is outside the iptables lock section (claim_lock "iptables") and even if it is only a read-only operation the underlying iptables operatio

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

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

Re: [Xen-devel] [PATCH 1/3] x86/emul: Introduce build time assertions for struct segment_register

>>> On 30.06.17 at 17:04, wrote: > This structure is shared with hardware in the AMD VMCB. Indeed, but do we really depend on that in the emulator code? > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -7899,6 +7899,12 @@ static void __init __may

Re: [Xen-devel] [PATCH 2/3] x86/hvm: Rearange check_segment() to use a switch statement

>>> On 30.06.17 at 17:04, wrote: > +case x86_seg_ds: > +case x86_seg_es: > +if ( (reg->attr.fields.type & 0x8) && !(reg->attr.fields.type & 0x2) > ) > +{ > +gprintk(XENLOG_ERR, "Non-readable segment provided for DS or > ES\n"); > +return -EINVAL; >

Re: [Xen-devel] [PATCH 3/3] x86/emul: Drop segment_attributes_t

>>> On 30.06.17 at 17:04, wrote: > The amount of namespace resolution is unnecessarily large, as all code deals > in terms of struct segment_register. This removes the attr.fields part of all > references, and alters attr.bytes to just attr. Yeah, quite a bit easier to read and type this way. >

Re: [Xen-devel] [PATCH v3 04/11] libxl: add generic function to add device

On Fri, Jun 30, 2017 at 5:18 PM, Wei Liu wrote: > On Fri, Jun 30, 2017 at 03:16:38PM +0100, Wei Liu wrote: >> On Fri, Jun 30, 2017 at 04:24:23PM +0300, Oleksandr Grytsov wrote: >> > On Thu, Jun 29, 2017 at 8:36 PM, Wei Liu wrote: >> > > On Tue, Jun 27, 2017 at 01:03:20PM +0300, Oleksandr Grytsov

Re: [Xen-devel] [PATCH v12 15/23] x86: refactor psr: CDP: implement set value callback function.

On 17-07-03 03:18:05, Jan Beulich wrote: > >>> On 03.07.17 at 10:40, wrote: > > On 17-07-03 01:01:09, Jan Beulich wrote: > >> >>> On 03.07.17 at 08:33, wrote: > >> > On 17-06-30 06:02:32, Jan Beulich wrote: > >> >> >>> Yi Sun 06/30/17 1:30 PM >>> > > > > To decide the return value, we have to k

Re: [Xen-devel] [PATCH 00/18] x86: more bool_t to bool cleanup

On Mon, Jul 03, 2017 at 02:10:03AM -0600, Jan Beulich wrote: > >>> On 30.06.17 at 19:01, wrote: > > Seeing that bool_t keeps creeping back in new patches I think the only > > solution > > is to get rid of bool_t once and for all, as soon as possible. > > I don't fully agree, and considering the

Re: [Xen-devel] [PATCH v3 04/11] libxl: add generic function to add device

On Mon, Jul 03, 2017 at 03:53:08PM +0300, Oleksandr Grytsov wrote: > On Fri, Jun 30, 2017 at 5:18 PM, Wei Liu wrote: > > On Fri, Jun 30, 2017 at 03:16:38PM +0100, Wei Liu wrote: > >> On Fri, Jun 30, 2017 at 04:24:23PM +0300, Oleksandr Grytsov wrote: > >> > On Thu, Jun 29, 2017 at 8:36 PM, Wei Liu

[Xen-devel] [PATCH] kbdif: Define "feature-raw-pointer" and "request-raw-pointer"

Backends set "feature-raw-pointer" if its capable of reporting absolute positions without scaling the coordinates to screen size. This should be set during the backend init. Frontends set "request-raw-pointer" to request that backends do not rescale absolute coordinates to screen size, and the coor

Re: [Xen-devel] RT-Xen on ARM

On Mon, Jul 03, 2017 at 02:03:33PM +0300, Andrii Anisov wrote: > Dear Meng Xu, > > We are going to evaluate an RTDS scheduler on ARM. > > Basically I'm going to repeat use-cases described in > https://www.cis.upenn.edu/~linhphan/papers/emsoft14-rt-xen.pdf in some > amount. > > Do you have any re

Re: [Xen-devel] [PATCH v12 15/23] x86: refactor psr: CDP: implement set value callback function.

>>> On 03.07.17 at 14:52, wrote: > Ok. Then, how about below change? Thanks! > int ret = 0; > for ( i = 0; i < props->cos_num; i++ ) > { > if ( type == props->type[i] ) > { > val[i] = new_val; > ret = 0; > break; > } >

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

flight 111332 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/111332/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 19 leak-check/checkfail REGR. vs. 110515 Tests which did not

Re: [Xen-devel] race in vif-common.sh

CC George (author of recent change) and Ian On Mon, Jul 03, 2017 at 01:30:09PM +0200, Andreas Kinzler wrote: > Hello > > in /etc/xen/scripts/vif-common.sh there is a function handle_iptable. > At its start there is a check for a working iptables implementation. > This check is outside the iptable

Re: [Xen-devel] [PATCH 1/3] x86/emul: Introduce build time assertions for struct segment_register

On 03/07/17 13:29, Jan Beulich wrote: On 30.06.17 at 17:04, wrote: >> This structure is shared with hardware in the AMD VMCB. > Indeed, but do we really depend on that in the emulator code? > >> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >> @@

Re: [Xen-devel] [PATCH v5 02/12] arm/mem_access: Move PAGE_SHIFT_* macros to lib.h

Hi Jan, On 07/03/2017 11:16 AM, Jan Beulich wrote: On 03.07.17 at 11:03, wrote: >> To prevent potential type width issues with ARMv7, I would reuse the >> macro from xen/iommu.h at this point: >> >> PAGE_MASK_GRAN(sz) (~(u64)0 << PAGE_SHIFT_##sz) > Seems reasonable, exce

[Xen-devel] [PATCH 4/3] x86/svm: Drop svm_segment_register_t

Most SVM code already uses struct segment_register. Drop the typedef and adjust the definitions in struct vmcb_struct, and svm_dump_sel(). Introduce some build-time assertions that struct segment_register from the common emulation code is usable in struct vmcb_struct. While making these adjustme

Re: [Xen-devel] [PATCH 2/3] x86/hvm: Rearange check_segment() to use a switch statement

On 03/07/17 13:34, Jan Beulich wrote: On 30.06.17 at 17:04, wrote: >> +case x86_seg_ds: >> +case x86_seg_es: >> +if ( (reg->attr.fields.type & 0x8) && !(reg->attr.fields.type & >> 0x2) ) >> +{ >> +gprintk(XENLOG_ERR, "Non-readable segment provided for DS o

Re: [Xen-devel] [PATCH v5 02/12] arm/mem_access: Move PAGE_SHIFT_* macros to lib.h

Hi Jan, On 07/03/2017 11:13 AM, Jan Beulich wrote: On 03.07.17 at 10:40, wrote: >> On 06/27/2017 02:04 PM, Jan Beulich wrote: >> Sergej Proskurin 06/27/17 1:52 PM >>> The following commits introduce a software guest page table walk software implementation that supports varyin

[Xen-devel] [PATCH 1/2 v2] xenfb: Use qemu_input_handler_* calls directly

The xenvkbd input device uses functions from input-legacy.c Use the appropriate qemu_input_handler_* functions instead of calling functions in input-legacy.c that in turn call the correct functions. The bulk of this patch removes the extra layer of calls by moving the required structure members int

[Xen-devel] [PATCH 0/2 v2] xenfb: Fix protocol for HVM guests

This series is intended to alow HVM guests to use the vkbd device with a PV frontend driver. Initial version at: http://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenvkbd.git;a=tree Since the vkbd device is initialised for HVM guests, using the vkbd device can allow the disabling of the USB controlle

[Xen-devel] [PATCH 2/2 v2] xenfb: Allow vkbd to connect without a DisplayState

If the vkbd device model is registered and the vfb device model is not registered, the backend will not transition to connected. If there is no DisplayState, then the absolute coordinates cannot be scaled, and will remain in the range [0, 0x7fff]. Backend writes "feature-raw-pointer" to indicate th

Re: [Xen-devel] [PATCH 00/18] x86: more bool_t to bool cleanup

>>> On 03.07.17 at 14:54, wrote: > On Mon, Jul 03, 2017 at 02:10:03AM -0600, Jan Beulich wrote: >> >>> On 30.06.17 at 19:01, wrote: >> > Seeing that bool_t keeps creeping back in new patches I think the only > solution >> > is to get rid of bool_t once and for all, as soon as possible. >> >> I

Re: [Xen-devel] [PATCH 3/3] x86/emul: Drop segment_attributes_t

On 03/07/17 13:50, Jan Beulich wrote: On 30.06.17 at 17:04, wrote: >> The amount of namespace resolution is unnecessarily large, as all code deals >> in terms of struct segment_register. This removes the attr.fields part of >> all >> references, and alters attr.bytes to just attr. > Yeah, q

Re: [Xen-devel] [PATCH v5 02/12] arm/mem_access: Move PAGE_SHIFT_* macros to lib.h

>>> On 03.07.17 at 15:07, wrote: > On 07/03/2017 11:16 AM, Jan Beulich wrote: > On 03.07.17 at 11:03, wrote: >>> To prevent potential type width issues with ARMv7, I would reuse the >>> macro from xen/iommu.h at this point: >>> >>> PAGE_MASK_GRAN(sz) (~(u64)0 << PAGE_SHIFT

Re: [Xen-devel] RT-Xen on ARM

On 03.07.17 16:03, Wei Liu wrote: This is a bit strange, fc658208e026242420b9924a9e4bfa581479e1f5 seems to imply xentop should work on ARM. Yep it is built. But yocto missed its installation. That issue is on our site :) -- *Andrii Anisov* ___ Xe

Re: [Xen-devel] [PATCH v5 02/12] arm/mem_access: Move PAGE_SHIFT_* macros to lib.h

>>> On 03.07.17 at 15:17, wrote: > On 07/03/2017 11:13 AM, Jan Beulich wrote: > On 03.07.17 at 10:40, wrote: >>> On 06/27/2017 02:04 PM, Jan Beulich wrote: >>> Sergej Proskurin 06/27/17 1:52 PM >>> > The following commits introduce a software guest page table walk > software impl

Re: [Xen-devel] [PATCH 1/3] x86/emul: Introduce build time assertions for struct segment_register

>>> On 03.07.17 at 15:05, wrote: > On 03/07/17 13:29, Jan Beulich wrote: > On 30.06.17 at 17:04, wrote: >>> This structure is shared with hardware in the AMD VMCB. >> Indeed, but do we really depend on that in the emulator code? >> >>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >>> +++ b/xe

Re: [Xen-devel] [PATCH 2/3] x86/hvm: Rearange check_segment() to use a switch statement

>>> On 03.07.17 at 15:15, wrote: > On 03/07/17 13:34, Jan Beulich wrote: > On 30.06.17 at 17:04, wrote: >>> +case x86_seg_ds: >>> +case x86_seg_es: >>> +if ( (reg->attr.fields.type & 0x8) && !(reg->attr.fields.type & >>> 0x2) ) >>> +{ >>> +gprintk(XENLOG_E

Re: [Xen-devel] RT-Xen on ARM

On Mon, Jul 3, 2017 at 7:03 AM, Andrii Anisov wrote: > > Dear Meng Xu, Hi Andrii, > > > We are going to evaluate an RTDS scheduler on ARM. > > > Basically I'm going to repeat use-cases described in > https://www.cis.upenn.edu/~linhphan/papers/emsoft14-rt-xen.pdf in some amount. I see. Please

Re: [Xen-devel] [PATCH 4/3] x86/svm: Drop svm_segment_register_t

>>> On 03.07.17 at 15:10, wrote: > --- a/xen/arch/x86/hvm/svm/vmcb.c > +++ b/xen/arch/x86/hvm/svm/vmcb.c > @@ -310,6 +310,15 @@ void __init setup_vmcb_dump(void) > register_keyhandler('v', vmcb_dump, "dump AMD-V VMCBs", 1); > } > > +static void __init __maybe_unused build_assertions(void)

Re: [Xen-devel] [PATCH 1/3] x86/emul: Introduce build time assertions for struct segment_register

On 03/07/17 14:32, Jan Beulich wrote: On 03.07.17 at 15:05, wrote: >> On 03/07/17 13:29, Jan Beulich wrote: >> On 30.06.17 at 17:04, wrote: This structure is shared with hardware in the AMD VMCB. >>> Indeed, but do we really depend on that in the emulator code? >>> --- a/xen/ar

Re: [Xen-devel] [PATCH 4/3] x86/svm: Drop svm_segment_register_t

On 03/07/17 14:37, Jan Beulich wrote: On 03.07.17 at 15:10, wrote: >> --- a/xen/arch/x86/hvm/svm/vmcb.c >> +++ b/xen/arch/x86/hvm/svm/vmcb.c >> @@ -310,6 +310,15 @@ void __init setup_vmcb_dump(void) >> register_keyhandler('v', vmcb_dump, "dump AMD-V VMCBs", 1); >> } >> >> +static void

Re: [Xen-devel] Optimising the DevSummit schedule on July 11

On Mon, Jul 03, 2017 at 11:37:29AM +0100, Lars Kurth wrote: > Folks, (committers and speakers/moderators CC'ed) > > I have a few extra sessions from Jan which came in today. Most of Tuesday > in x86 stuff, so there is no space. I merged one of my session with a proposal > from Jan, but it seems to

Re: [Xen-devel] [PATCH 2/3] x86/hvm: Rearange check_segment() to use a switch statement

On 03/07/17 14:33, Jan Beulich wrote: On 03.07.17 at 15:15, wrote: >> On 03/07/17 13:34, Jan Beulich wrote: >> On 30.06.17 at 17:04, wrote: +case x86_seg_ds: +case x86_seg_es: +if ( (reg->attr.fields.type & 0x8) && !(reg->attr.fields.type & 0x2) ) >>>

Re: [Xen-devel] [PATCH 2/3] x86/hvm: Rearange check_segment() to use a switch statement

>>> On 03.07.17 at 15:58, wrote: > On 03/07/17 14:33, Jan Beulich wrote: > On 03.07.17 at 15:15, wrote: >>> On 03/07/17 13:34, Jan Beulich wrote: >>> On 30.06.17 at 17:04, wrote: > +case x86_seg_ds: > +case x86_seg_es: > +if ( (reg->attr.fields.type & 0x8) &&

Re: [Xen-devel] [PATCH 4/3] x86/svm: Drop svm_segment_register_t

>>> On 03.07.17 at 15:39, wrote: > On 03/07/17 14:37, Jan Beulich wrote: > On 03.07.17 at 15:10, wrote: >>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>> @@ -310,6 +310,15 @@ void __init setup_vmcb_dump(void) >>> register_keyhandler('v', vmcb_dump, "dump AMD

Re: [Xen-devel] [PATCH] kbdif: Define "feature-raw-pointer" and "request-raw-pointer"

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Owen Smith > Sent: 03 July 2017 13:58 > To: xen-devel@lists.xen.org > Cc: andr2...@gmail.com; sstabell...@kernel.org; Owen Smith > > Subject: [Xen-devel] [PATCH] kbdif: Define "feature-raw-pointe

Re: [Xen-devel] [PATCH 3/6] x86/shadow: Use ERR_PTR infrastructure for sh_emulate_map_dest()

On 22/06/17 10:07, Jan Beulich wrote: On 22.06.17 at 10:21, wrote: >> On 22/06/2017 09:14, Jan Beulich wrote: >> On 21.06.17 at 17:12, wrote: sh_emulate_map_dest() predates the introduction of the generic ERR_PTR() infrasturcture, but take the opportunity to avoid opencoding it

Re: [Xen-devel] [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes

>>> On 30.06.17 at 22:15, wrote: > /* > * Set access permissions, cacheability and shareability (ARM only) of a > * continuos range of normal memory (RAM) in the stage-2 page table. > */ > /* XEN_DOMCTL_memattrs_op */ > > /* set chacheability and shareability */ > #define XEN_DOMCTL_MEMATTRS_O

Re: [Xen-devel] [PATCH 3/6] x86/shadow: Use ERR_PTR infrastructure for sh_emulate_map_dest()

>>> On 03.07.17 at 16:22, wrote: > On 22/06/17 10:07, Jan Beulich wrote: > On 22.06.17 at 10:21, wrote: >>> On 22/06/2017 09:14, Jan Beulich wrote: >>> On 21.06.17 at 17:12, wrote: > sh_emulate_map_dest() predates the introduction of the generic ERR_PTR() > infrasturcture, but ta

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

On 29/06/17 16:17, Vikram Sethi wrote: Hi Julien, Hi Vikram, My thoughts are that while it is not essential to recover from AER and DPC initially, it is critical to at least take the slot offline and notify drivers so they quiesce. Without this basic handling, it is possible to create bac

Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

On 06/30/2017 02:42 PM, George Dunlap wrote: On 06/28/2017 05:18 PM, Ross Lagerwall wrote: On 06/27/2017 10:17 AM, George Dunlap wrote: On 26/06/17 18:30, Andrew Cooper wrote: On 26/06/17 18:00, George Dunlap wrote: On 26/06/17 16:36, Ross Lagerwall wrote: ... We absolutely cannot be in th

[Xen-devel] [PATCH v3] livepatch: Declare live patching as a supported feature

See docs/features/livepatch.pandoc for the details. Turn live patching on by default on supported platforms (x86). Signed-off-by: Ross Lagerwall Reviewed-by: Konrad Rzeszutek Wilk --- Changed in v3: Default to on for supported platforms (X86). docs/features/livepatch.pandoc | 103 +++

[Xen-devel] Ping: Re: [PATCH 2/2] x86: don't allow clearing of TF_kernel_mode for other than 64-bit PV

>>> On 31.05.17 at 13:54, wrote: On 31.05.17 at 13:08, wrote: > > On 31/05/17 08:15, Jan Beulich wrote: > >> The flag is really only meant for those, both HVM and 32-bit PV tell > >> kernel from user mode based on CPL/RPL. Remove the all-question-marks > >> comment and let's be on the safe s

[Xen-devel] Ping: [PATCH 1/2] hvmloader: dynamically determine scratch memory range for tests

>>> On 31.05.17 at 09:37, wrote: > This re-enables tests on configurations where commit 0d6968635c > ("hvmloader: avoid tests when they would clobber used memory") forced > them to be skipped. > > Signed-off-by: Jan Beulich > > --- a/tools/firmware/hvmloader/tests.c > +++ b/tools/firmware/hvmlo

Re: [Xen-devel] RT-Xen on ARM

Hello Meng Xu, On 03.07.17 16:35, Meng Xu wrote: Do you have any recommendations or suggestions? Which experiment/use case do you plan to run? What are the requirements (or performance guarantees) you want to have from RTDS? Currently we have no defined target use-cases. That's why we are goi

Re: [Xen-devel] [PATCH 6/6] x86/hvm: Implement hvmemul_write() using real mappings

On 22/06/17 10:06, Jan Beulich wrote: > >> +/* >> + * mfn points to the next free slot. All used slots have a page >> reference >> + * held on them. >> + */ >> +mfn_t *mfn = &hvmemul_ctxt->mfn[0]; >> + >> +/* >> + * The caller has no legitimate reason for trying a zero

Re: [Xen-devel] [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes

Hi Julien, 2017-07-03 19:16 GMT+08:00 Julien Grall : > Hi, > > On 01/07/17 10:16, Zhongze Liu wrote: >>> >>> On the ARM side, we are missing BUFFERABLE and WRITEALLOC. I don't know >>> how they map to these tags, which comes from the x86 world. Maybe we >>> should just add them separately as ARM o

[Xen-devel] [PATCH] xen/balloon: don't online new memory initially

When setting up the Xenstore watch for the memory target size the new watch will fire at once. Don't try to reach the configured target size by onlining new memory in this case, as the current memory size will be smaller in almost all cases due to e.g. BIOS reserved pages. Onlining new memory will

Re: [Xen-devel] [PATCH v5 03/11] x86/mce: handle host LMCE

>>> On 03.07.17 at 05:46, wrote: > @@ -454,6 +455,7 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs) > uint64_t gstatus; > mctelem_cookie_t mctc = NULL; > struct mca_summary bs; > +bool wait, lmce; Considering the code being replaced as well as ... > @@ -462,6 +464

Re: [Xen-devel] [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes

Hi Jan, 2017-07-03 22:25 GMT+08:00 Jan Beulich : On 30.06.17 at 22:15, wrote: >> /* >> * Set access permissions, cacheability and shareability (ARM only) of a >> * continuos range of normal memory (RAM) in the stage-2 page table. >> */ >> /* XEN_DOMCTL_memattrs_op */ >> >> /* set chacheab

Re: [Xen-devel] [PATCH 6/6] x86/hvm: Implement hvmemul_write() using real mappings

>>> On 03.07.17 at 17:07, wrote: > On 22/06/17 10:06, Jan Beulich wrote: >>> +{ >>> +ASSERT_UNREACHABLE(); >>> +goto unhandleable; >>> +} >>> + >>> +do { >>> +enum hvm_translation_result res; >>> +struct page_info *page; >>> +pagefault_info_t pfi

Re: [Xen-devel] [PATCH] xen/balloon: don't online new memory initially

>>> On 03.07.17 at 17:40, wrote: > --- a/drivers/xen/xen-balloon.c > +++ b/drivers/xen/xen-balloon.c > @@ -59,6 +59,8 @@ static void watch_target(struct xenbus_watch *watch, > { > unsigned long long new_target; > int err; > + static bool watch_fired; > + static unsigned long t

Re: [Xen-devel] [PATCH] xen/balloon: don't online new memory initially

On 03/07/17 18:11, Jan Beulich wrote: On 03.07.17 at 17:40, wrote: >> --- a/drivers/xen/xen-balloon.c >> +++ b/drivers/xen/xen-balloon.c >> @@ -59,6 +59,8 @@ static void watch_target(struct xenbus_watch *watch, >> { >> unsigned long long new_target; >> int err; >> +static bool

[Xen-devel] [RTDS Patch v3 for Xen4.8]

From: naroahlee When more than one idle VCPUs that have the same PCPU as their previous running core invoke runq_tickle(), they will tickle the same PCPU. The tickled PCPU will only pick at most one VCPU, i.e., the highest-priority one, to execute. The other VCPUs will not be scheduled for a

Re: [Xen-devel] [PATCH 1/2] hvmloader: dynamically determine scratch memory range for tests

On 31/05/17 08:37, Jan Beulich wrote: > This re-enables tests on configurations where commit 0d6968635c > ("hvmloader: avoid tests when they would clobber used memory") forced > them to be skipped. > > Signed-off-by: Jan Beulich I still fail to see the value in retaining these tests. They only c

Re: [Xen-devel] [PATCH v2 2/2] tools: utility to dump guest grant table info

On Mon, Jul 03, 2017 at 07:34:13AM +0800, Dongli Zhang wrote: > As both xen-netfront and xen-blkfront support multi-queue, they would > consume a lot of grant table references when there are many paravirtual > devices and vcpus assigned to guest. Guest domU might panic or hang due to > grant alloca

Re: [Xen-devel] [PATCH v2 1/2] tools/libxc: add interface for GNTTABOP_query_size

On Mon, Jul 03, 2017 at 07:34:12AM +0800, Dongli Zhang wrote: > This patch adds new interface for GNTTABOP_query_size in libxc to help > query the current grant table frames and maximum grant table frames for a > specific domain. > > Signed-off-by: Dongli Zhang Acked-by: Wei Liu __

[Xen-devel] [linux-4.9 test] 111336: tolerable FAIL - PUSHED

flight 111336 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/111336/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 15 guest-stop fail in 111294 pass in 111336 test-armhf-armhf-xl

[Xen-devel] [OSSTEST PATCH 2/3] mg-schema-test-database: New --max-flight option

This can be useful when testing things which involve old data, rather than things which just involve new data. Signed-off-by: Ian Jackson --- mg-schema-test-database | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/mg-schema-test-database b/mg-schema-test-database i

  1   2   >