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 09-03-1
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 host-install(3
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 setup_fixmap_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)
+{
+ __set_fixmap(get_cpu_gdt_ro_index(cpu),
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 prelink.o
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
test-amd64-i386-xl-qemuu-
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
test-armhf-armhf-xl
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
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 rcu_dereference to stop sparse complai
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
test-amd64-amd64-lib
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). Unfortuna
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
> ---
> tools/libxc/include/xenctrl.h | 2 ++
> tools/libxc/xc_mon
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 be usable by a guest on itself?
Arguably the same question wou
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 zone_
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 runqueu
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 runqueu
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 making it behave like this: There's no need
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
>
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, wrote:
>> The domain builder in libxc no longer depends on leaked CPU
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 t
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
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
---
CC: Jan Beulich
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 update_domain_
>>> 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 Beulich
>
> --- a/
>>> 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 existing continuation model used
>>> 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 ( !rc )
> +{
> +switc
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
test-amd64-i386-xl-qemuu-wi
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 re
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 +++
tools/tests/xen-access/xen-access.
>>> 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 it).
> + *
> +
>>> 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 expensive,
> and we can avoid t
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, M
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
test-amd64-i386-xl-qemuu-
>>> 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, simply parse them one afte
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 07-03-1
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
test-armhf-armhf-xl
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 th
> > 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
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 event
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 the other sub-ops
>>> too, but anyway.
>>
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 which could not be run:
>> te
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()) {
>>> acpi_table_parse_srat(TYPE_CPU_AFFINITY);
>>
>> Thi
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 as below.
ubuntu@ubunt
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é
Signe
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 s
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 v9fs transport.
> >
> > All functions are
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 for address
translation. So
>>> 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[], uint32_t array_len)
>> > +{
>> > +if ( !data || 2 > arra
>>> 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 l3_cat_fits_cos_max(const uint64_t val[],
>> > +
>>> 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 l3_cat_compare_val(const uint64_t val[],
>> > +
>>> 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;
>> > }
>> >
>> > +static bool psr_check_cbm(unsign
>>> 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 )
>> > +unsigned int socket, cos;
>>
>>> 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)
>> > +{
>> > +return -ENOENT;
>> > +}
>>
>> Is this functi
>>> 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 != feat_type )
>> > continue;
>> >
>> > +
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 @@ enum psr_feat_type {
> >> > PSR_SOCKET_L3_CA
>>> 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 = 0,
>> > PSR_SOCKET_L3_CDP,
>> > PSR_SOCKE
>>> 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 *info;
>> > +unsigned int socket;
>> > +unsigne
>>> 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 easier"). Here is a
>>> set of changes that remove the use of
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
test-amd64-i386-xl-qemuu-
>>> 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:
> test-armhf-armhf-xl-arndale 3 host-install(3)
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 with NDEBUG
and LivePatch e
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(
a.u.set_mem_access.view);
bre
62 matches
Mail list logo
