Re: [Xen-devel] [PATCH v2] boot allocator: Use arch helper for virt_to_mfn on DIRECTMAP

On Mon, Mar 13, 2017 at 7:12 PM, Jan Beulich wrote: On 13.03.17 at 12:43, wrote: >> --- a/xen/include/asm-arm/mm.h >> +++ b/xen/include/asm-arm/mm.h >> @@ -260,6 +260,13 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t >> *pa, unsigned int

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

> and ARCH_SPARSEMEM_DEFAULT is enabeld on 64b. So I guess whatever was > the reason to add this code back in 2006 is not true anymore. So I am > really wondering. Do we absolutely need to assign pages which are not > onlined yet to the ZONE_NORMAL unconditionally? Why cannot we put them > out of

Re: [Xen-devel] [PATCH v8 08/24] x86: refactor psr: set value: implement framework.

On 17-03-13 06:35:33, Jan Beulich wrote: > >>> On 13.03.17 at 03:36, wrote: > > On 17-03-10 02:09:55, Jan Beulich wrote: > >> >>> On 10.03.17 at 03:54, wrote: > >> > On 17-03-08 09:07:10, Jan Beulich wrote: > >> >> >>> On 15.02.17 at 09:49,

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

flight 106641 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/106641/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. vs. 106574

Re: [Xen-devel] [PATCH v8 09/24] x86: refactor psr: set value: assemble features value array.

On 17-03-13 06:37:41, Jan Beulich wrote: > >>> On 13.03.17 at 03:43, wrote: > > On 17-03-10 02:15:20, Jan Beulich wrote: > >> >>> On 10.03.17 at 04:21, wrote: > >> > On 17-03-08 09:54:04, Jan Beulich wrote: > >> >> >>> On 15.02.17 at 09:49,

Re: [Xen-devel] [Question] About the behavior of HLT in VMX guest mode

Hi Jan, On 2017/3/13 19:38, Jan Beulich wrote: On 13.03.17 at 06:12, wrote: >> I'm confusing about the behavior of HLT instruction in VMX guest mode. >> >> I set "hlt exiting" bit to 0 in VMCS, and the vcpu didn't vmexit when execute >> HLT as expected. However, I

[Xen-devel] [ovmf test] 106638: regressions - FAIL

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

Re: [Xen-devel] [PATCH v3] xen: don't save/restore the physmap on VM save/restore

On 13/03/17 21:15, Stefano Stabellini wrote: > On Mon, 13 Mar 2017, Igor Druzhinin wrote: >> Saving/restoring the physmap to/from xenstore was introduced to >> QEMU majorly in order to cover up the VRAM region restore issue. >> The sequence of restore operations implies that we should know >> the

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

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

[Xen-devel] [PATCH v2 3/9] xen: introduce the header file for the Xen 9pfs transport protocol

It uses the new ring.h macros to declare rings and interfaces. Signed-off-by: Stefano Stabellini CC: anthony.per...@citrix.com CC: jgr...@suse.com --- hw/9pfs/xen_9pfs.h | 20 1 file changed, 20 insertions(+) create mode 100644 hw/9pfs/xen_9pfs.h diff

[Xen-devel] [PATCH v2 8/9] xen/9pfs: send responses back to the frontend

Once a request is completed, xen_9pfs_push_and_notify gets called. In xen_9pfs_push_and_notify, update the indexes (data has already been copied to the sg by the common code) and send a notification to the frontend. Schedule the bottom-half to check if we already have any other requests pending.

[Xen-devel] [PATCH v2 2/9] xen: import ring.h from xen

Do not use the ring.h header installed on the system. Instead, import the header into the QEMU codebase. This avoids problems when QEMU is built against a Xen version too old to provide all the ring macros. Signed-off-by: Stefano Stabellini CC: anthony.per...@citrix.com CC:

[Xen-devel] [PATCH v2 9/9] xen/9pfs: build and register Xen 9pfs backend

Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz CC: anthony.per...@citrix.com CC: jgr...@suse.com CC: Aneesh Kumar K.V CC: Greg Kurz --- hw/9pfs/Makefile.objs| 1 + hw/xen/xen_backend.c

[Xen-devel] [PATCH v2 5/9] xen/9pfs: connect to the frontend

Write the limits of the backend to xenstore. Connect to the frontend. Upon connection, allocate the rings according to the protocol specification. Initialize a QEMUBH to schedule work upon receiving an event channel notification from the frontend. Signed-off-by: Stefano Stabellini

[Xen-devel] [PATCH v2 7/9] xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal

Implement xen_9pfs_init_in/out_iov_from_pdu and xen_9pfs_pdu_vmarshal/vunmarshall by creating new sg pointing to the data on the ring. This is safe as we only handle one request per ring at any given time. Signed-off-by: Stefano Stabellini CC: anthony.per...@citrix.com CC:

[Xen-devel] [PATCH v2 4/9] xen/9pfs: introduce Xen 9pfs backend

Introduce the Xen 9pfs backend: add struct XenDevOps to register as a Xen backend and add struct V9fsTransport to register as v9fs transport. All functions are empty stubs for now. Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz CC:

[Xen-devel] [PATCH v2 6/9] xen/9pfs: receive requests from the frontend

Upon receiving an event channel notification from the frontend, schedule the bottom half. From the bottom half, read one request from the ring, create a pdu and call pdu_submit to handle it. For now, only handle one request per ring at a time. Signed-off-by: Stefano Stabellini

[Xen-devel] [PATCH v2 1/9] configure: change CONFIG_XEN_BACKEND to be a target property

CONFIG_XEN_BACKEND is currently set when the host supports Xen, regardless of the chosen targets. As a consequence, Xen backends can be enabled even on targets that don't support Xen. Fix the issue by setting CONFIG_XEN_BACKEND only for targets that support Xen. Signed-off-by: Stefano Stabellini

[Xen-devel] [PATCH v2 0/9] xen/9pfs: introduce the Xen 9pfs backend

Hi all, This patch series implements a new transport for 9pfs, aimed at Xen systems. The transport is based on a traditional Xen frontend and backend drivers pair. This patch series implements the backend, which typically runs in Dom0. I sent another series to implement the frontend in Linux

[Xen-devel] [PATCH v3 6/7] xen/9pfs: receive responses

Upon receiving a notification from the backend, schedule the p9_xen_response work_struct. p9_xen_response checks if any responses are available, if so, it reads them one by one, calling p9_client_cb to send them up to the 9p layer (p9_client_cb completes the request). Handle the ring following the

[Xen-devel] [PATCH v3 2/7] xen: introduce the header file for the Xen 9pfs transport protocol

It uses the new ring.h macros to declare rings and interfaces. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- include/xen/interface/io/9pfs.h | 40 1 file changed,

[Xen-devel] [PATCH v3 5/7] xen/9pfs: send requests to the backend

Implement struct p9_trans_module create and close functions by looking at the available Xen 9pfs frontend-backend connections. We don't expect many frontend-backend connections, thus walking a list is OK. Send requests to the backend by copying each request to one of the available rings (each

[Xen-devel] [PATCH v3 4/7] xen/9pfs: connect to the backend

Implement functions to handle the xenbus handshake. Upon connection, allocate the rings according to the protocol specification. Initialize a work_struct and a wait_queue. The work_struct will be used to schedule work upon receiving an event channel notification from the backend. The wait_queue

[Xen-devel] [PATCH v3 3/7] xen/9pfs: introduce Xen 9pfs transport driver

Introduce the Xen 9pfs transport driver: add struct xenbus_driver to register as a xenbus driver and add struct p9_trans_module to register as v9fs driver. All functions are empty stubs for now. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky

[Xen-devel] [PATCH v3 1/7] xen: import new ring macros in ring.h

Sync the ring.h file with upstream Xen, to introduce the new ring macros. They will be used by the Xen transport for 9pfs. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- NB: The new macros have not been

[Xen-devel] [PATCH v3 7/7] xen/9pfs: build 9pfs Xen transport driver

This patch adds a Kconfig option and Makefile support for building the 9pfs Xen driver. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com CC: Eric Van Hensbergen CC: Ron Minnich CC: Latchesar Ionkov

[Xen-devel] [PATCH v3 0/7] Xen transport for 9pfs frontend driver

Hi all, This patch series implements a new transport for 9pfs, aimed at Xen systems. The transport is based on a traditional Xen frontend and backend drivers pair. This patch series implements the frontend, which typically runs in a regular unprivileged guest. I also sent a series that

[Xen-devel] [seabios test] 106637: tolerable FAIL - PUSHED

flight 106637 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/106637/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106381

Re: [Xen-devel] [Qemu-devel] [PATCH 3/8] xen/9pfs: introduce Xen 9pfs backend

On Fri, 10 Mar 2017, Greg Kurz wrote: > On Thu, 9 Mar 2017 18:54:26 +0100 > Greg Kurz wrote: > > > On Mon, 6 Mar 2017 18:12:43 -0800 > > Stefano Stabellini wrote: > > > > > Introduce the Xen 9pfs backend: add struct XenDevOps to register as a > > > Xen

Re: [Xen-devel] [PATCH 0/7] Xen transport for 9pfs frontend driver

On Thu, 9 Mar 2017, Roger Pau Monné wrote: > On Tue, Mar 07, 2017 at 10:27:05AM -0800, Stefano Stabellini wrote: > > On Tue, 7 Mar 2017, Roger Pau Monné wrote: > > > On Mon, Mar 06, 2017 at 12:00:41PM -0800, Stefano Stabellini wrote: > > > > Hi all, > > > > > > > > This patch series implements a

Re: [Xen-devel] [PATCH v2 4/7] xen/9pfs: connect to the backend

On Thu, 9 Mar 2017, Boris Ostrovsky wrote: > > + > > +static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev, > > + struct xen_9pfs_dataring *ring) > > +{ > > + int i; > > + int ret = -ENOMEM; > > + > > + init_waitqueue_head(>wq); > > + spin_lock_init(>lock); > > +

Re: [Xen-devel] [PATCH v2 3/7] xen/9pfs: introduce Xen 9pfs transport driver

On Thu, 9 Mar 2017, Boris Ostrovsky wrote: > On 03/08/2017 06:58 PM, Stefano Stabellini wrote: > > Introduce the Xen 9pfs transport driver: add struct xenbus_driver to > > register as a xenbus driver and add struct p9_trans_module to register > > as v9fs driver. > > > > All functions are empty

Re: [Xen-devel] [raisin] Using cirros for tests???

On Thu, 9 Mar 2017, Gémes Géza wrote: > Hi, > > I've sent my last couple of days on trying to make raisin tests run on > different distributions. Tried Ubuntu 16.04, Ubuntu 14.04, CentOS 7 and CentOS > 6.8 so far. The tests fail because of different reasons on these > distributions: > > 1.

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

> @@ -2642,6 +2660,38 @@ void svm_vmexit_handler(struct cpu_user_regs *regs) > case VMEXIT_PAUSE: > svm_vmexit_do_pause(regs); > break; > + > +case VMEXIT_IDTR_READ: > +hvm_descriptor_access_intercept(vmcb->exitintinfo.bytes, 0, > VM_EVENT_DESC_IDTR, 0); >

Re: [Xen-devel] [PATCH v3] xen: don't save/restore the physmap on VM save/restore

On Mon, 13 Mar 2017, Igor Druzhinin wrote: > Saving/restoring the physmap to/from xenstore was introduced to > QEMU majorly in order to cover up the VRAM region restore issue. > The sequence of restore operations implies that we should know > the effective guest VRAM address *before* we have the

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

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

[Xen-devel] [linux-next test] 106632: regressions - FAIL

flight 106632 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/106632/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 9 redhat-install fail REGR. vs. 106553

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

flight 106635 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/106635/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 14 guest-start/debian.repeat fail REGR. vs. 106574 Regressions

Re: [Xen-devel] [PATCH v3 1/4] ocaml/gen: fix ocaml type/code generator from IDL

> On 13 Mar 2017, at 16:49, Wei Liu wrote: > > On Fri, Mar 03, 2017 at 12:25:05PM +, Roger Pau Monne wrote: >> From: Ian Jackson >> >> This patch adds support for union members which have their own type name. >> >> Signed-off-by: Ian

[Xen-devel] [PATCH v3] xen: don't save/restore the physmap on VM save/restore

Saving/restoring the physmap to/from xenstore was introduced to QEMU majorly in order to cover up the VRAM region restore issue. The sequence of restore operations implies that we should know the effective guest VRAM address *before* we have the VRAM region restored (which happens later).

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

On Mon, Mar 13, 2017 at 11:32 AM, Boris Ostrovsky wrote: > There are a couple of problems for Xen PV guests that need to be addressed: > 1. Xen's set_fixmap op needs non-default handling for > FIX_GDT_REMAP_BEGIN range > 2. GDT remapping for PV guests needs to be RO

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

On 03/09/2017 06:17 PM, Boris Ostrovsky wrote: > On 03/09/2017 05:31 PM, Thomas Garnier wrote: >> On Thu, Mar 9, 2017 at 2:13 PM, Boris Ostrovsky >> wrote: > I don't have any experience with Xen so it would be great if virtme can > test it. I am pretty

Re: [Xen-devel] [RFC XTF PATCH] Pagetable Emulation testing

On 13/03/17 15:45, Jan Beulich wrote: On 06.03.17 at 17:42, wrote: >> +struct mapping_info >> +{ >> +unsigned int level, order; >> +void *va; >> +intpte_t *pte, *fe_pte; > Having got quite a bit into the patch, I think I've finally understood that >

Re: [Xen-devel] Mapping active GDT

On Mon, Mar 13, 2017 at 10:32 AM, Boris Ostrovsky wrote: > No, it will need a few small changes. I am actually finishing the test > run (in the next hour or so) and will reply on the Linux thread. > Great, thanks again! -- Thomas

Re: [Xen-devel] Mapping active GDT

On 03/13/2017 01:30 PM, Thomas Garnier wrote: > On Mon, Mar 13, 2017 at 6:09 AM, Boris Ostrovsky > wrote: >> On 03/11/2017 08:06 AM, Andrew Cooper wrote: >>> On 11/03/2017 03:58, Boris Ostrovsky wrote: On 03/10/2017 09:39 PM, Boris Ostrovsky wrote: > I am

Re: [Xen-devel] Mapping active GDT

On Mon, Mar 13, 2017 at 6:09 AM, Boris Ostrovsky wrote: > On 03/11/2017 08:06 AM, Andrew Cooper wrote: >> On 11/03/2017 03:58, Boris Ostrovsky wrote: >>> On 03/10/2017 09:39 PM, Boris Ostrovsky wrote: I am looking into GDT remap series [0] which crashes PV guests

Re: [Xen-devel] [PATCH V2] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

On Mon, Mar 13, 2017 at 6:29 AM, Razvan Cojocaru wrote: > On 03/13/2017 02:19 PM, Jan Beulich wrote: > On 13.03.17 at 13:01, wrote: >>> On 03/10/2017 09:01 PM, Tamas K Lengyel wrote: On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper

[Xen-devel] [ovmf test] 106634: regressions - FAIL

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

Re: [Xen-devel] [PATCH 01/16] tools: fix typo in tools/Rules.mk

On Wed, Mar 08, 2017 at 03:49:30PM +0100, Juergen Gross wrote: > Commit 78fb69ad9 ("tools/Rules.mk: Properly handle libraries with > recursive dependencies.") introduced a copy and paste error in > tools/Rules.mk: > > LDLIBS_libxenstore and SHLIB_libxenstore don't use SHDEPS_libxenstore > but

Re: [Xen-devel] [PATCH v3 1/4] ocaml/gen: fix ocaml type/code generator from IDL

On Fri, Mar 03, 2017 at 12:25:05PM +, Roger Pau Monne wrote: > From: Ian Jackson > > This patch adds support for union members which have their own type name. > > Signed-off-by: Ian Jackson Reviewed-by: Wei Liu

Re: [Xen-devel] [PATCH v3 2/4] x86: remove PVHv1 code

On Fri, Mar 03, 2017 at 12:25:06PM +, Roger Pau Monne wrote: > This removal applies to both the hypervisor and the toolstack side of PVHv1. > > Note that on the toolstack side a new PVH domain type is introduced to libxl. > The "none" device model version is removed, together with the "pvh"

Re: [Xen-devel] [RFC XTF PATCH] Pagetable Emulation testing

>>> On 06.03.17 at 17:42, wrote: > +struct mapping_info > +{ > +unsigned int level, order; > +void *va; > +intpte_t *pte, *fe_pte; Having got quite a bit into the patch, I think I've finally understood that "fe" here is meant to match up with "fep" - a

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

>2017-03-13 19:52 GMT+08:00 Jan Beulich : @@ -1566,14 +1557,14 @@ void __init noreturn __start_xen(unsigned long mbi_p) /* Grab the DOM0 command line. */ cmdline = (char *)(mod[0].string ? __va(mod[0].string) : NULL); -if ( (cmdline

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

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

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

Let's add Andi On Fri 10-03-17 16:53:33, Michal Hocko wrote: > On Fri 10-03-17 14:58:07, Michal Hocko wrote: > [...] > > This would explain why onlining from the last block actually works but > > to me this sounds like a completely crappy behavior. All we need to > > guarantee AFAICS is that

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote: >> > >> > What is the API those guests ask for the memory? And who is actually >> > responsible to ask for that memory? Is it a kernel or userspace >> > solution? >> >> Whatever, this can even be a

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote: I agree with your general sentiment that this stuff is very nonintuitive. My criterion for nonintuitive is probably different because I would call this _completely_unusable_. Sorry for being so loud about this but the more I look

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon 13-03-17 14:57:12, Igor Mammedov wrote: > On Mon, 13 Mar 2017 11:43:02 +0100 > Michal Hocko wrote: > > > On Mon 13-03-17 11:31:10, Igor Mammedov wrote: > > > On Fri, 10 Mar 2017 14:58:07 +0100 > > [...] > > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote: > >> Michal Hocko writes: > >> > >> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > >> >> > > > >> >> > >-

Re: [Xen-devel] [PATCH 3/4] x86emul: correct handling of FPU insns faulting on memory write

On 13/03/17 11:05, Jan Beulich wrote: > When an FPU instruction with a memory destination fails during the > memory write, it should not affect FPU register state. Due to the way > we emulate FPU (and SIMD) instructions, we can only guarantee this by > - backing out changes to the FPU register

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon, 13 Mar 2017 11:43:02 +0100 Michal Hocko wrote: > On Mon 13-03-17 11:31:10, Igor Mammedov wrote: > > On Fri, 10 Mar 2017 14:58:07 +0100 > [...] > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009] > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem

Re: [Xen-devel] [PATCH v2] boot allocator: Use arch helper for virt_to_mfn on DIRECTMAP

>>> On 13.03.17 at 12:43, wrote: > --- a/xen/include/asm-arm/mm.h > +++ b/xen/include/asm-arm/mm.h > @@ -260,6 +260,13 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t > *pa, unsigned int flags) > #define virt_to_mfn(va) (virt_to_maddr(va) >> PAGE_SHIFT) >

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote: >> Michal Hocko writes: >> >> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: >> >> > > >> >> > >- suggested RFC is not acceptable from virt point of view >> >> > >

Re: [Xen-devel] [PATCH v2 04/10] x86/cpuid: Handle leaf 0x4 in guest_cpuid()

>>> On 13.03.17 at 14:24, wrote: > On 13/03/17 13:05, Jan Beulich wrote: > On 13.03.17 at 13:51, wrote: >>> On 13/03/17 12:03, Jan Beulich wrote: >>> On 10.03.17 at 17:27, wrote: > @@ -242,6 +243,25 @@

Re: [Xen-devel] [PATCH v2 04/10] x86/cpuid: Handle leaf 0x4 in guest_cpuid()

On 13/03/17 13:05, Jan Beulich wrote: On 13.03.17 at 13:51, wrote: >> On 13/03/17 12:03, Jan Beulich wrote: >> On 10.03.17 at 17:27, wrote: @@ -242,6 +243,25 @@ static void __init calculate_raw_policy(void)

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > >> > > > >> > >- suggested RFC is not acceptable from virt point of view > >> > > as it regresses guests on top of x86 kvm/vmware

Re: [Xen-devel] Mapping active GDT

On 03/11/2017 08:06 AM, Andrew Cooper wrote: > On 11/03/2017 03:58, Boris Ostrovsky wrote: >> On 03/10/2017 09:39 PM, Boris Ostrovsky wrote: >>> I am looking into GDT remap series [0] which crashes PV guests and it >>> seems that the problem lies in the fact that we cannot establish new >>>

Re: [Xen-devel] [PATCH v2 04/10] x86/cpuid: Handle leaf 0x4 in guest_cpuid()

>>> On 13.03.17 at 13:51, wrote: > On 13/03/17 12:03, Jan Beulich wrote: > On 10.03.17 at 17:27, wrote: >>> @@ -242,6 +243,25 @@ static void __init calculate_raw_policy(void) >>> cpuid_leaf(i, >basic.raw[i]); >>> } >>> >>>

Re: [Xen-devel] [PATCH v2 00/21] x86/xen: untangle PV and PVHVM guest support code

Boris Ostrovsky writes: > On 03/02/2017 12:53 PM, Vitaly Kuznetsov wrote: >> Changes since v1: >> - Patches 1,2 and 3 were split and reordered to avoid adding temporary >>#ifdefs [Juergen Gross] >> - Juergen's R-b added to what is now patches 14 and 15 (patches 4

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: >> > > >> > >- suggested RFC is not acceptable from virt point of view >> > > as it regresses guests on top of x86 kvm/vmware which >> > > both use ACPI based memory hotplug. >> >

Re: [Xen-devel] [PATCH v2 04/10] x86/cpuid: Handle leaf 0x4 in guest_cpuid()

On 13/03/17 12:03, Jan Beulich wrote: On 10.03.17 at 17:27, wrote: >> Leaf 0x4 is reserved by AMD. For Intel, it is a multi-invocation leaf with >> ecx enumerating different cache details. >> >> Add a new union for it in struct cpuid_policy, collect it from

Re: [Xen-devel] [PATCH V2] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

On 03/13/2017 02:40 PM, Jan Beulich wrote: On 13.03.17 at 13:29, wrote: >> On 03/13/2017 02:19 PM, Jan Beulich wrote: >>> I think as long as there's no need for the guest to use an operation >>> on itself, it should not be a hvmop. After all, if you make it a

Re: [Xen-devel] [PATCH V2] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

>>> On 13.03.17 at 13:29, wrote: > On 03/13/2017 02:19 PM, Jan Beulich wrote: >> I think as long as there's no need for the guest to use an operation >> on itself, it should not be a hvmop. After all, if you make it a domctl >> now and later find a need for it to be

Re: [Xen-devel] [PATCH v8 09/24] x86: refactor psr: set value: assemble features value array.

>>> On 13.03.17 at 03:43, wrote: > On 17-03-10 02:15:20, Jan Beulich wrote: >> >>> On 10.03.17 at 04:21, wrote: >> > On 17-03-08 09:54:04, Jan Beulich wrote: >> >> >>> On 15.02.17 at 09:49, wrote: >> >> > @@ -207,6

Re: [Xen-devel] [PATCH v8 08/24] x86: refactor psr: set value: implement framework.

>>> On 13.03.17 at 03:36, wrote: > On 17-03-10 02:09:55, Jan Beulich wrote: >> >>> On 10.03.17 at 03:54, wrote: >> > On 17-03-08 09:07:10, Jan Beulich wrote: >> >> >>> On 15.02.17 at 09:49, wrote: >> >> > +

Re: [Xen-devel] [PATCH 2/4] x86emul: centralize put_fpu() invocations

>>> On 13.03.17 at 12:55, wrote: > On 13/03/17 11:03, Jan Beulich wrote: >> @@ -1006,22 +1007,31 @@ do { >> rc = _get_fpu(_type, _fic, ctxt, ops); \ >> if ( rc ) goto done;\ >> } while (0) >>

Re: [Xen-devel] [PATCH V2] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

On 03/13/2017 02:19 PM, Jan Beulich wrote: On 13.03.17 at 13:01, wrote: >> On 03/10/2017 09:01 PM, Tamas K Lengyel wrote: >>> On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper >>> wrote: On 10/03/17 07:34, Jan Beulich wrote:

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > On Thu, 9 Mar 2017 13:54:00 +0100 > Michal Hocko wrote: > > [...] > > > It's major regression if you remove auto online in kernels that > > > run on top of x86 kvm/vmware hypervisors, making API cleanups > > > while breaking

Re: [Xen-devel] [PATCH V2] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

>>> On 13.03.17 at 13:01, wrote: > On 03/10/2017 09:01 PM, Tamas K Lengyel wrote: >> On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper >> wrote: >>> On 10/03/17 07:34, Jan Beulich wrote: >>> On 09.03.17 at 18:29, wrote:

Re: [Xen-devel] [PATCH v2 08/10] x86/cpuid: Handle leaf 0xb in guest_cpuid()

>>> On 10.03.17 at 17:44, wrote: > @@ -938,6 +927,21 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf, > } > break; > > +case 0xb: > +/* > + * In principle, this leaf is Intel-only. In practice, it is tightly > + *

Re: [Xen-devel] [PATCH v2 06/10] x86/cpuid: Handle leaf 0x6 in guest_cpuid()

>>> On 10.03.17 at 17:32, wrote: > The thermal/performance leaf was previously hidden from HVM guests, but fully > visible to PV guests. Most of the leaf refers to MSR availability, and there > is nothing an unprivileged PV guest can do with the information, so hide

Re: [Xen-devel] [PATCH v2 04/10] x86/cpuid: Handle leaf 0x4 in guest_cpuid()

>>> On 10.03.17 at 17:27, wrote: > Leaf 0x4 is reserved by AMD. For Intel, it is a multi-invocation leaf with > ecx enumerating different cache details. > > Add a new union for it in struct cpuid_policy, collect it from hardware in > calculate_raw_policy(), audit it

Re: [Xen-devel] [PATCH V2] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

On 03/10/2017 09:01 PM, Tamas K Lengyel wrote: > On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper > wrote: >> On 10/03/17 07:34, Jan Beulich wrote: >> On 09.03.17 at 18:29, wrote: On Thu, Mar 9, 2017 at 9:56 AM, Jan Beulich

Re: [Xen-devel] [PATCH 2/4] x86emul: centralize put_fpu() invocations

On 13/03/17 11:03, Jan Beulich wrote: > ..., splitting parts of it into check_*() macros. This is in > preparation of making ->put_fpu() do further adjustments to register > state. (Some of the check_xmm() invocations could be avoided, as in > some of the cases no insns handled there can actually

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

>>> On 10.03.17 at 18:36, wrote: > 2017-03-10 23:03 GMT+08:00 Jan Beulich : > On 09.03.17 at 04:13, wrote: >>> If CMDLINE is set, the cmdline_parse() routine will append the bootloader >>> command line to this string, forming the

Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

>>> On 10.03.17 at 18:10, wrote: > On 28/02/17 09:31, Jan Beulich wrote: > On 27.02.17 at 16:10, wrote: >>> On 22/02/17 10:10, Jan Beulich wrote: >>> On 22.02.17 at 11:00, wrote: > On 22/02/17 09:23,

[Xen-devel] [xen-unstable test] 106627: tolerable FAIL

flight 106627 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/106627/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-cubietruck 16 guest-start.2fail pass in 106605 Regressions which are regarded

Re: [Xen-devel] Xen 4.6.5 released

>>> On 13.03.17 at 12:22, wrote: > On 13/03/17 10:59, Jan Beulich wrote: > On 13.03.17 at 11:29, wrote: >>> On 13/03/17 09:24, Jan Beulich wrote: >>> On 10.03.17 at 18:22, wrote: > On 08.03.2017 13:54,

[Xen-devel] [PATCH v2] boot allocator: Use arch helper for virt_to_mfn on DIRECTMAP

From: Vijaya Kumar K On ARM, virt_to_mfn uses the hardware for address translation. So if the virtual address is not mapped translation fault is raised.On ARM, DIRECTMAP_VIRT region is direct mapped. On ARM with NUMA, While initializing second memory node, panic is

Re: [Xen-devel] [Question] About the behavior of HLT in VMX guest mode

>>> On 13.03.17 at 06:12, wrote: > I'm confusing about the behavior of HLT instruction in VMX guest mode. > > I set "hlt exiting" bit to 0 in VMCS, and the vcpu didn't vmexit when execute > HLT as expected. However, I used powertop/cpupower on host to watch the pcpu's >

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

>>> On 11.03.17 at 09:42, wrote: > On 3/11/2017 12:59 AM, Andrew Cooper wrote: >> On 08/03/17 15:33, Yu Zhang wrote: >>> --- a/xen/arch/x86/hvm/dm.c >>> +++ b/xen/arch/x86/hvm/dm.c >>> @@ -288,6 +288,7 @@ static int inject_event(struct domain *d, >>> return 0;

Re: [Xen-devel] [PATCH 1/4] x86emul: fold exit paths

On 13/03/17 11:03, Jan Beulich wrote: > Move "cannot_emulate" and make it go through the common (error) exit > path. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list

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

>>> On 11.03.17 at 09:42, wrote: > On 3/11/2017 12:17 AM, Jan Beulich wrote: > On 08.03.17 at 16:33, wrote: >>> --- a/xen/include/asm-x86/p2m.h >>> +++ b/xen/include/asm-x86/p2m.h >>> @@ -611,6 +611,11 @@ void

Re: [Xen-devel] [PATCH v7 4/5] ix86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.

>>> On 11.03.17 at 09:42, wrote: > On 3/11/2017 12:03 AM, Jan Beulich wrote: >> But there's a wider understanding issue I'm having here: What is >> an "entry" here? Commonly I would assume this to refer to an >> individual (4k) page, but it looks like you really mean

Re: [Xen-devel] Xen 4.6.5 released

On 13/03/17 10:59, Jan Beulich wrote: On 13.03.17 at 11:29, wrote: >> On 13/03/17 09:24, Jan Beulich wrote: >> On 10.03.17 at 18:22, wrote: On 08.03.2017 13:54, Jan Beulich wrote: > All, > > I am pleased to announce

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

>>> On 11.03.17 at 09:42, wrote: > On 3/10/2017 11:33 PM, Jan Beulich wrote: > On 08.03.17 at 16:33, wrote: >>> @@ -197,6 +217,10 @@ static int hvmemul_do_io( >>>* - If the IOREQ_MEM_ACCESS_WRITE flag is not set, treat it

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

>>> On 11.03.17 at 09:42, wrote: > On 3/10/2017 11:29 PM, Jan Beulich wrote: > On 08.03.17 at 16:33, wrote: >>> changes in v7: >>>- Use new ioreq server interface - XEN_DMOP_map_mem_type_to_ioreq_server. >>>- According to

Re: [Xen-devel] [GSoC] GSoC Introduction : Fuzzing Xen hypercall interface

Hi Felix Thanks for your interest in this project. On Sun, Mar 12, 2017 at 09:48:11PM +0100, Felix Ekkehard Schmoll wrote: > Hi, > > I’m interested in the “Fuzzing Xen hypercall interface” project so I > just wanted to introduce myself: > > I’m a third-year undergraduate CS student at Jacobs

[Xen-devel] [PATCH][XTF] add FPU/SIMD register state test

Add tests to verify that - FPU insns leave correct (guest) values in FIP/FDP/FOP/FCS/FDS, - FPU insns writing memory don't update FPU register state when the write faults (at the example of FISTP), - VCVTPS2PH (once implemented in the emulator) doesn't update MXCSR if its write faults

[Xen-devel] [PATCH 4/4] x86emul: correct FPU code/data pointers and opcode handling

Prevent leaking the hypervisor ones (stored by hardware during stub execution), at once making sure the guest sees correct values there. This piggybacks on the backout logic used to deal with write faults of FPU insns. Deliberately ignore the NO_FPU_SEL feature here: Honoring it would merely mean

  1   2   >