Re: [Xen-devel] WTH is going on with memory hotplug sysf interface

On 03/10/2017 08:58 AM, Michal Hocko wrote: Let's CC people touching this logic. A short summary is that onlining memory via udev is currently unusable for online_movable because blocks are added from lower addresses while movable blocks are allowed from last blocks. More below. On Thu

[Xen-devel] [qemu-mainline baseline-only test] 68648: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 68648 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68648/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 3

Re: [Xen-devel] Mapping active GDT

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 > mapping to an already existing GDT. > > The mapping is created by > > +static inline void

[Xen-devel] Mapping active GDT

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 mapping to an already existing GDT. The mapping is created by +static inline void setup_fixmap_gdt(int cpu) +{ +

Re: [Xen-devel] [PATCH 2/2] build/clang: fix XSM dummy policy when using clang 4.0

On 03/06/2017 07:31 AM, Roger Pau Monne wrote: There seems to be some weird bug in clang 4.0 that prevents xsm_pmu_op from working as expected, and vpmu.o ends up with a reference to __xsm_action_mismatch_detected which makes the build fail: [...] ld-melf_x86_64_fbsd -T xen.lds -N

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

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

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

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

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

Hey, On Mon, Mar 06, 2017 at 03:54:17PM +0100, Michal Hocko wrote: [...] > So let's discuss the current memory hotplug shortcomings and get rid of > the crud which developed on top. I will start by splitting up the patch > into 3 parts. Do the auto online thing from the HyperV and xen balloning

[Xen-devel] [PATCH net v4] xen-netback: fix race condition on XenBus disconnect

In some cases during XenBus disconnect event handling and subsequent queue resource release there may be some TX handlers active on other processors. Use RCU in order to synchronize with them. Signed-off-by: Igor Druzhinin --- v4: * Use READ_ONCE instead of

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

flight 106587 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/106587/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 16 guest-localmigrate/x10 fail REGR. vs. 106570

[Xen-devel] [PATCH v2] 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] x86/monitor: add support for descriptor access events

On Fri, Mar 10, 2017 at 8:50 AM, Vlad Ioan Topan wrote: > Adds monitor support for descriptor access events (reads & writes of > IDTR/GDTR/LDTR/TR) for the x86 architecture (VMX and SVM). > > Signed-off-by: Vlad Ioan Topan > --- >

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

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 wrote: However - is this interface supposed to

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 Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: OK, so while I was playing with this setup some more I probably got why this is done this way. All new memblocks are added to the zone Normal where they are accounted as spanned but not present. It's not always zone Normal. See

[Xen-devel] [PATCH RFC 2/2] xen: credit2: flexible configuration of runqueues

The idea is to give user more flexibility to configure runqueue further. For most workloads and in most systems, using per-core means have too many small runqueues. Using per-socket is almost always better, but it may result in too few big runqueues. OPTION 1 : The user can create

[Xen-devel] [PATCH RFC 1/2] xen: credit2: flexible configuration of runqueues

The idea is to give user more flexibility to configure runqueue further. For most workloads and in most systems, using per-core means have too many small runqueues. Using per-socket is almost always better, but it may result in too few big runqueues. OPTION 1 : The user can create

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

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 complete command line >> before parsing. > > I disagree to

Re: [Xen-devel] Xen 4.6.5 released

On 08.03.2017 13:54, Jan Beulich wrote: > All, > > I am pleased to announce the release of Xen 4.6.5. This is > available immediately from its git repository > http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.6 > (tag RELEASE-4.6.5) or from the XenProject download page >

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

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, Jan Beulich wrote: On 20.02.17 at 12:00,

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

On 08/03/17 15:33, Yu Zhang wrote: > 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

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

Leaf 0xb is reserved by AMD, and uniformly hidden from guests by the toolstack logic and hypervisor PV logic. The previous dynamic logic filled in the x2APIC ID for all HVM guests. In practice, leaf 0xb is tightly linked with x2APIC, and x2APIC is offered to guests on AMD hardware, as Xen's APIC

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

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 the leaf entirely. Signed-off-by: Andrew Cooper

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

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 in recalculate_cpuid_policy() and update guest_cpuid() and

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

>>> On 03.03.17 at 15:29, wrote: > This was my originally intended fix for the AMD side of XSA-207: > There's no need to unconditionally allocate the root table, and with > that there's then also no way to leak it when a guest has no devices > assigned. > > Signed-off-by: Jan

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

>>> On 08.03.17 at 16:33, 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; > } > > +#define DMOP_op_mask 0xff > static int dm_op(domid_t domid, Please follow the

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

>>> On 08.03.17 at 16:33, wrote: > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -954,6 +954,26 @@ int p2m_change_type_one(struct domain *d, unsigned long > gfn, > p2m->default_access) > : -EBUSY; > > +if (

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

flight 106584 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/106584/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106534

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 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 Normal and Movable zones do not overlap. I > believe there is even no real

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

Adds monitor support for descriptor access events (reads & writes of IDTR/GDTR/LDTR/TR) for the x86 architecture (VMX and SVM). Signed-off-by: Vlad Ioan Topan --- tools/libxc/include/xenctrl.h | 2 ++ tools/libxc/xc_monitor.c| 14 +++

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

>>> 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 > * like a normal PIO or MMIO that doesn't have an ioreq > * server (i.e., by ignoring

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 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 comments from George: removed domain_pause/unpause() in > hvm_map_mem_type_to_ioreq_server(), because it's too

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

On Fri, Mar 10, 2017 at 12:23:18PM +0900, Roger Pau Monné wrote: > On Thu, Mar 09, 2017 at 07:29:34PM -0500, Konrad Rzeszutek Wilk wrote: > > On Thu, Mar 09, 2017 at 01:26:45PM +, Julien Grall wrote: > > > Hi Konrad, > > > > > > On 09/03/17 11:17, Konrad Rzeszutek Wilk wrote: > > > > On Thu,

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

flight 106586 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/106586/ 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 v4] xen: Allow a default compiled-in command line using Kconfig

>>> 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 complete command line > before parsing. I disagree to making it behave like this: There's no need to concatenate both,

[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 CC people touching this logic. A short summary is that onlining memory via udev is currently unusable for online_movable because blocks are added from lower addresses while movable blocks are allowed from last blocks. More below. On Thu 09-03-17 13:54:00, Michal Hocko wrote: > On Tue

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

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

Re: [Xen-devel] Enabling #VE for a domain from dom0

On 10/03/17 11:57, Vlad-Ioan TOPAN wrote: >>> Is there any reason for the other check I've mentioned, performed when >>> setting the "suppres #VE" bit in PTEs? Unsuppressing #VEs for a page >>> will only do anything if the guest has already enabled #VE, so the >>> previous issue doesn't apply in

Re: [Xen-devel] Enabling #VE for a domain from dom0

> > Is there any reason for the other check I've mentioned, performed when > > setting the "suppres #VE" bit in PTEs? Unsuppressing #VEs for a page > > will only do anything if the guest has already enabled #VE, so the > > previous issue doesn't apply in this case. > > suppress #VE has a negative

[Xen-devel] Xen Project Developer and Design Summit location and CfP pre-announcement - also looking for PMC members

Dear community members, just a quick note to let you know about the upcoming next steps for the Xen Project Developer and Design Summit. The event location and date will be Corinthia Hotel, Budapest (http://www.corinthia.com/en/hotels/budapest) July 11- 13 Note that this will be a 3 day

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

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 wrote: >>> However - is this interface supposed to be usable by a guest on itself? >>> Arguably the same question would apply to some of

Re: [Xen-devel] [xen-unstable test] 106580: regressions - trouble: blocked/broken/fail/pass

On 10/03/17 08:37, Jan Beulich wrote: On 10.03.17 at 08:20, wrote: >> flight 106580 xen-unstable real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/106580/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests

Re: [Xen-devel] [RFC PATCH v1 16/21] ARM: NUMA: Extract proximity from SRAT table

On Fri, Mar 3, 2017 at 8:52 PM, Jan Beulich wrote: On 03.03.17 at 16:16, wrote: >> On Fri, Mar 3, 2017 at 8:22 PM, Julien Grall wrote: >>> int __init acpi_numa_init(void) >>> { >>> if (!acpi_parse_table()) { >>>

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

On Fri, Mar 10, 2017 at 3:09 PM, Julien Grall wrote: > Hello, > > It is not the first time I am saying this. Please CC *all* the maintainers > of the code you modify. Give a look at scripts/get_maintainers.pl. I got below maintainers when I ran the script on complete patch

[Xen-devel] [PATCH] tools/kdd: don't use a pointer to an unaligned field.

The 'val' field in the packet is byte-aligned (because it is part of a packed struct), but the pointer argument to kdd_rdmsr() has the normal alignment constraints for a uint64_t *. Use a local variable to make sure the passed pointer has the correct alignment. Reported-by: Roger Pau Monné

Re: [Xen-devel] [PATCH] tools/kdd: remove unneeded packed attributes

Hi, At 12:02 +0900 on 10 Mar (1489147353), Roger Pau Monne wrote: > The layout of the structures make them already aligned, there's no need for > the > packed attributes. That's not right -- kdd_pkt gets 8 bytes longer with this patch. In fact this code has the bug that clang's new warning is

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

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 backend and add struct V9fsTransport to register as

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

Hello, It is not the first time I am saying this. Please CC *all* the maintainers of the code you modify. Give a look at scripts/get_maintainers.pl. On 03/10/2017 07:32 AM, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K On ARM, virt_to_mfn uses the hardware

Re: [Xen-devel] [PATCH v8 18/24] x86: L2 CAT: implement get hw info flow.

>>> On 10.03.17 at 06:57, wrote: > On 17-03-09 08:13:59, Jan Beulich wrote: >> >>> On 15.02.17 at 09:49, wrote: >> > +static bool l2_cat_get_feat_info(const struct feat_node *feat, >> > + uint32_t data[],

Re: [Xen-devel] [PATCH v8 11/24] x86: refactor psr: set value: implement cos id picking flow.

>>> On 10.03.17 at 06:40, wrote: > On 17-03-09 07:10:33, Jan Beulich wrote: >> >>> On 15.02.17 at 09:49, wrote: >> > @@ -397,6 +408,25 @@ static int l3_cat_compare_val(const uint64_t val[], >> > return 0; >> > } >> > >> > +static bool

Re: [Xen-devel] [PATCH v8 10/24] x86: refactor psr: set value: implement cos finding flow.

>>> On 10.03.17 at 06:35, wrote: > On 17-03-08 10:03:10, Jan Beulich wrote: >> >>> On 15.02.17 at 09:49, wrote: >> > @@ -356,6 +369,34 @@ static int l3_cat_set_new_val(uint64_t val[], >> > return 0; >> > } >> > >> > +static int

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

>>> 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 +233,29 @@ static enum psr_feat_type >> > psr_cbm_type_to_feat_type(enum cbm_type type) >> > return feat_type;

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

>>> On 10.03.17 at 08:46, wrote: > On 17-03-08 09:07:10, Jan Beulich wrote: > [...] >> > /* Called with domain lock held, no extra lock needed for 'psr_cos_ids' */ >> > static void psr_free_cos(struct domain *d) >> > { >> > -if( !d->arch.psr_cos_ids ) >> > +

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

>>> 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: >> > +static int write_psr_msr(unsigned int socket, unsigned int cos, >> > + const uint64_t *val) >> > +{ >>

Re: [Xen-devel] [PATCH v8 07/24] x86: refactor psr: implement get value flow.

>>> On 10.03.17 at 02:50, wrote: > On 17-03-08 08:35:53, Jan Beulich wrote: >> >>> On 15.02.17 at 09:49, wrote: >> > @@ -498,6 +516,15 @@ int psr_get_info(unsigned int socket, enum cbm_type >> > type, >> > if ( feat->feature !=

Re: [Xen-devel] [PATCH v8 06/24] x86: refactor psr: implement get hw info flow.

On 17-03-10 01:57:57, Jan Beulich wrote: > >>> On 10.03.17 at 02:43, wrote: > > On 17-03-08 08:15:33, Jan Beulich wrote: > >> >>> On 15.02.17 at 09:49, wrote: > >> > --- a/xen/arch/x86/psr.c > >> > +++ b/xen/arch/x86/psr.c > >> > @@ -84,6 +84,7

Re: [Xen-devel] [PATCH v8 06/24] x86: refactor psr: implement get hw info flow.

>>> On 10.03.17 at 02:43, wrote: > On 17-03-08 08:15:33, Jan Beulich wrote: >> >>> On 15.02.17 at 09:49, wrote: >> > --- a/xen/arch/x86/psr.c >> > +++ b/xen/arch/x86/psr.c >> > @@ -84,6 +84,7 @@ enum psr_feat_type { >> > PSR_SOCKET_L3_CAT

Re: [Xen-devel] [PATCH v8 04/24] x86: refactor psr: implement CPU init and free flow.

>>> On 10.03.17 at 02:32, wrote: > On 17-03-08 07:56:54, Jan Beulich wrote: >> >>> On 15.02.17 at 09:49, wrote: >> > -static int psr_cpu_prepare(unsigned int cpu) >> > +static void cpu_init_work(void) >> > +{ >> > +struct psr_socket_info

Re: [Xen-devel] [PATCH v2 0/6] Remove dependency on __LINE__

>>> On 10.03.17 at 09:29, wrote: > On 03/09/2017 10:34 AM, Jan Beulich wrote: > On 08.03.17 at 18:46, wrote: >>> Sorry for the long delay since the first version of this series >>> (previously called "Make building xSplice patches

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

flight 106582 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/106582/ 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] [xen-unstable test] 106580: regressions - trouble: blocked/broken/fail/pass

>>> On 10.03.17 at 08:20, wrote: > flight 106580 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/106580/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

Re: [Xen-devel] [PATCH v2 0/6] Remove dependency on __LINE__

On 03/09/2017 10:34 AM, Jan Beulich wrote: On 08.03.17 at 18:46, wrote: Sorry for the long delay since the first version of this series (previously called "Make building xSplice patches easier"). Here is a set of changes that remove the use of __LINE__ when building

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

On 03/10/2017 09:31 AM, Jan Beulich wrote: On 09.03.17 at 18:15, wrote: >> On 03/09/2017 06:56 PM, Jan Beulich wrote: >> On 09.03.17 at 10:38, wrote: @@ -4535,6 +4536,30 @@ static int do_altp2m_op(