flight 63654 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63654/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 6 xen-bootfail REGR. vs. 59254
test-amd64-amd64-xl-p
This run is configured for baseline tests only.
flight 38253 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38253/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 7 host-ping-che
On Wed, Oct 28, 2015 at 10:05:31AM -0600, Jan Beulich wrote:
> >>> On 27.10.15 at 21:36, wrote:
> > +static void __init add_extra_rmrr(void)
> > +{
> > +struct acpi_rmrr_unit *acpi_rmrr;
> > +struct acpi_rmrr_unit *rmrru;
> > +unsigned int dev, seg, i;
> > +unsigned long pfn;
> > +
On 11/05/2015 05:31 PM, H. Peter Anvin wrote:
On 11/05/15 10:56, Boris Ostrovsky wrote:
The range between 0x8000 and 0x87ff is reserved
for hypervisor and therefore we should not try to follow PGD's indexes
corresponding to those addresses.
While this has alsways been
This run is configured for baseline tests only.
flight 38252 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38252/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 20 guest-start
On Thu, Nov 05, 2015 at 03:13:01AM -0700, Jan Beulich wrote:
> >>> On 05.11.15 at 10:57, wrote:
> > Ok. So alternative_input will not used here (means use the way
> > xrstor in Patch 8)? Or put the XSTATE_FIXUP into alternative_input ?
> > Which one is ok to you ?
>
> The latter, if necessary by
flight 63634 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63634/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build fail REGR. vs. 62648
Tests which are failin
flight 63602 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63602/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 6
Tests which did not succeed, but a
flight 63601 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63601/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build fail REGR. vs. 62642
Tests which are failin
On 11/05/15 10:56, Boris Ostrovsky wrote:
> The range between 0x8000 and 0x87ff is reserved
> for hypervisor and therefore we should not try to follow PGD's indexes
> corresponding to those addresses.
>
> While this has alsways been a problem, with commit e1a58320a38d ("x86
This run is configured for baseline tests only.
flight 38251 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38251/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf b9ffeab7b0856db6409b53efbba51b8c336b7491
baseline version:
ovm
On Mon, Nov 02, 2015 at 01:47:21PM +, Wei Liu wrote:
> Hi committers,
>
> There doesn't seem to be consensus on how release cycle should be
> managed. In the survey [0] about release cycle there were following
> proposed schemes:
>
> #1. 6 months release cycle + current stable release scheme
On Thu, Nov 05, 2015 at 06:31:22PM +, Lars Kurth wrote:
> Hi all,
>
> I was just informed that it is not going to be possible to hold the Developer
> Summit alongside LinuxCon in Berlin, unless we make some hard choices. I had
> originally had booked the space and all looked fine when it was
flight 63585 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63585/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-credit2 16 guest-start/debian.repeatfail like 63466
test-armhf-armhf-xl-rtds
On Thu, Nov 05, 2015 at 03:21:18PM +, Lars Kurth wrote:
> Hi all,
>
> I wanted to do quick straw-poll regarding Hackathon Locations for next year.
> Before I do this though, I wanted to let you know that the 2016 Developer
> Summit will most likely be in Berlin in October (I am in the proces
On Thu, Nov 05, 2015 at 11:15:34AM +, Ross Lagerwall wrote:
> On 11/04/2015 10:21 PM, Konrad Rzeszutek Wilk wrote:
> snip
> >>
> >>+
> >>+/*
> >>+ * The following functions prepare an xSplice module to be executed by
> >>+ * allocating space, loading the allocated sections, resolving symbols,
>
On Thu, Nov 05, 2015 at 11:45:42AM +, Ross Lagerwall wrote:
> On 11/05/2015 03:17 AM, Konrad Rzeszutek Wilk wrote:
> snip
> >>diff --git a/xen/arch/x86/xsplice.c b/xen/arch/x86/xsplice.c
> >>index dbff0d5..31e4124 100644
> >>--- a/xen/arch/x86/xsplice.c
> >>+++ b/xen/arch/x86/xsplice.c
> >>@@ -
On Thu, Nov 05, 2015 at 10:49:51AM +, Ross Lagerwall wrote:
> On 11/04/2015 09:10 PM, Konrad Rzeszutek Wilk wrote:
> snip
> >>+The payload **MUST** contain enough data to allow us to apply the update
> >>+and also safely reverse it. As such we **MUST** know:
> >>+
> >>+ * The locations in memor
On Thu, Nov 05, 2015 at 10:46:05AM +0800, Bob Liu wrote:
>
> On 11/05/2015 10:43 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 02, 2015 at 12:21:46PM +0800, Bob Liu wrote:
> >> Make pool of persistent grants and free pages per-queue/ring instead of
> >> per-device to get better scalability.
> >
flight 63599 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63599/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf b9ffeab7b0856db6409b53efbba51b8c336b7491
baseline version:
ovmf fad21b7c57336bbf0ae363d56e35cbccca6
On Tue, Nov 03, 2015 at 06:16:08PM +, Ross Lagerwall wrote:
> Add support for applying alternative sections within xsplice modules. At
> module load time, apply any alternative sections that are found.
>
> Signed-off-by: Ross Lagerwall
> ---
> xen/arch/x86/Makefile | 2 +-
> xen
On Tue, Nov 03, 2015 at 06:16:07PM +, Ross Lagerwall wrote:
> Add support for exception tables contained within xsplice modules. If an
> exception occurs search either the main exception table or a particular
> active module's exception table depending on the instruction pointer.
s/module/payl
On Tue, Nov 03, 2015 at 06:16:06PM +, Ross Lagerwall wrote:
> Add support for handling bug frames contained with xsplice modules. If a
> trap occurs search either the kernel bug table or an applied module's
payload.
> bug table depending on the instruction pointer.
>
> Signed-off-by: Ross Lag
I am trying to get xen running on an arndale Exynos5250. I think I am
close to success because I can boot the hypervisor and interact with the
debug console and I don't see any errors. I can switch the debug
console from xen mode to Dom0 mode by pressing CTRL-a three times,
however I am not promp
On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote:
> If Linux is running as dom0, call XENPF_settime to update the system
> time in Xen on pvclock_gtod notifications.
>
> Signed-off-by: Stefano Stabellini
> Signed-off-by: Ian Campbell
> ---
> arch/arm/xen/enlighten.c | 52
>
The range between 0x8000 and 0x87ff is reserved
for hypervisor and therefore we should not try to follow PGD's indexes
corresponding to those addresses.
While this has alsways been a problem, with commit e1a58320a38d ("x86/mm:
Warn on W^X mappings") ptdump_walk_pgd_level_co
On Thursday 05 November 2015 17:09:43 Stefano Stabellini wrote:
> Read the wallclock from the shared info page at boot time.
>
> Signed-off-by: Stefano Stabellini
Please use the appropriate timespec64 based functions here,
we are in the process of converting all callers of struct timespec.
> --
Hi all,
I was just informed that it is not going to be possible to hold the Developer
Summit alongside LinuxCon in Berlin, unless we make some hard choices. I had
originally had booked the space and all looked fine when it was originally
arranged several months ago. Seems that the LinuxCon orga
flight 63579 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63579/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 6 xen-boot fail REGR. vs. 63473
test-amd64-amd64-pygru
On 05/11/15 17:34, Julien Grall wrote:
> Hi Stefano,
>
> You forgot to CC Daniel for the XSM part. Please use
> scripts/get_maintainers.pl to get the relevant maintainers.
>
> On 05/11/15 16:57, Stefano Stabellini wrote:
>> Call update_domain_wallclock_time at domain initialization.
> It's not real
This is intended to decrease a time spending in transmitter
while waiting for the free space in TX FIFO.
And as result to reduce the impact of hvc on the entire system
running on OMAP5/DRA7XX based platforms.
Signed-off-by: Oleksandr Tyshchenko
CC: Ian Campbell
CC: Julien Grall
CC: Stefano Stab
The 8250-uart.h contains extra serial register definitions
for the internal UARTs in TI OMAP SoCs which are used in
OMAP UART driver only.
In order to clean up code move these definitions to omap-uart.c.
Also rename some definitions to follow to the UART_OMAP* prefix.
Signed-off-by: Oleksandr Tysh
Hi all,
Only second patch is related to the subject of the cover letter. The first
patch is clean up that was suggested during discussion of initial version:
http://www.gossamer-threads.com/lists/xen/devel/403859?page=last
Oleksandr Tyshchenko (2):
xen/serial: Move any OMAP specific things to OM
On 05/11/15 17:09, Stefano Stabellini wrote:
> If Linux is running as dom0, call XENPF_settime to update the system
> time in Xen on pvclock_gtod notifications.
Isn't this a cut-and-paste from x86? Can you make it common?
David
___
Xen-devel mailing l
On 05/11/15 14:36, Juergen Gross wrote:
> Support of an unmapped initrd is indicated by the kernel of the domain
> via elf notes. In order not to have to use raw elf data in the tools
> for support of an unmapped initrd add a flag to the parsed data area
> to indicate the kernel supporting this fea
Hi Stefano,
You forgot to CC Daniel for the XSM part. Please use
scripts/get_maintainers.pl to get the relevant maintainers.
On 05/11/15 16:57, Stefano Stabellini wrote:
> Call update_domain_wallclock_time at domain initialization.
It's not really what you are doing in the code. You are calling
On Thu, 5 Nov 2015, Peter Zijlstra wrote:
> How can this be missing? Things compile fine now, right?
Fair enough.
> So please better explain why we do this change.
asm/paravirt.h is included by one of the other headers included in
kernel/sched/cputime.c on x86, but not on other architecures. On
Thursday, November 5, 2015, 2:53:40 PM, you wrote:
> On 11/05/2015 04:13 AM, Sander Eikelenboom wrote:
>>
>> It makes "cat /sys/kernel/debug/kernel_page_tables" work and
>> prevents a kernel with CONFIG_DEBUG_WX=y from crashing at boot.
> Great. Our nightly runs also failed spectacularly due to
On Mon, 2 Nov 2015, Wei Liu wrote:
> Hi committers,
I am not a xen.git committer, but I am the qemu-xen.git committer, and
since I maintain all the qemu-xen stable trees and releases, I think
that my vote should count, at least for this proposal.
> There doesn't seem to be consensus on how relea
On 11/05/2015 04:13 AM, Sander Eikelenboom wrote:
It makes "cat /sys/kernel/debug/kernel_page_tables" work and
prevents a kernel with CONFIG_DEBUG_WX=y from crashing at boot.
Great. Our nightly runs also failed spectacularly due to this bug.
It now does give a warning about an insecure W+X
>>> On 05.11.15 at 18:09, wrote:
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
> HYPERCALL2(physdev_op);
> HYPERCALL3(vcpu_op);
> HYPERCALL1(tmem_op);
> +HYPERCALL1(dom0_op);
Assuming this somehow tries to mirror x86 naming - time
Hi Malcolm,
I tried your patches against staging yesterday and as soon as I started
a guest, it panic. I have lock_profile enabled and applied your patches
against:
6f04de658574833688c3f9eab310e7834d56a9c0 x86: cleanup of early cpuid
handling
(XEN) HVM1 save: CPU
(XEN) HVM1 save: PIC
(XE
Hi,
You forgot to CC the x86 maintainers.
Regards,
On 05/11/15 16:57, Stefano Stabellini wrote:
> Remove dummy arm implementation of wallclock_time.
> Use shared_info() in common code rather than x86-ism to access it.
>
> Signed-off-by: Stefano Stabellini
> Signed-off-by: Ian Campbell
> ---
>
>>> On 05.11.15 at 17:57, wrote:
> --- a/xen/common/time.c
> +++ b/xen/common/time.c
> @@ -16,7 +16,13 @@
> */
>
> #include
> +#include
> +#include
> +#include
> #include
> +#include
> +#include
> +
>
> /* Nonzero if YEAR is a leap year (every 4 years,
Stray blank line being added
On 5 November 2015 at 16:24, Wei Liu wrote:
>> We do have two options for a Hackathon: China (either Shanghai,
>> Hangzhou or Beijing - details TBC) and Cambridge, UK. We are still in
>> the early planning phase and the budget for the Hackathon has not yet
>> been approved.
>
> I lived in Hangzhou
>>> On 02.11.15 at 18:12, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -237,6 +237,7 @@ struct domain *alloc_domain_struct(void)
> #ifdef CONFIG_BIGMEM
> const unsigned int bits = 0;
> #else
> +int order = get_order_from_bytes(sizeof(*d));
unsigned int
> @@
Read the wallclock from the shared info page at boot time.
Signed-off-by: Stefano Stabellini
---
arch/arm/Kconfig |1 +
arch/arm/xen/enlighten.c | 31 +++
2 files changed, 32 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 60be104..
Signed-off-by: Stefano Stabellini
---
arch/arm/include/asm/xen/hypercall.h |2 ++
arch/arm/xen/enlighten.c |1 +
arch/arm/xen/hypercall.S |1 +
arch/arm64/xen/hypercall.S |1 +
4 files changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/xe
If Linux is running as dom0, call XENPF_settime to update the system
time in Xen on pvclock_gtod notifications.
Signed-off-by: Stefano Stabellini
Signed-off-by: Ian Campbell
---
arch/arm/xen/enlighten.c | 52 +-
1 file changed, 51 insertions(+), 1 d
Hi all,
this series introduces PV wallclock time support on arm and arm64.
Stefano Stabellini (3):
xen/arm: introduce xen_read_wallclock
xen/arm: introduce HYPERVISOR_dom0_op on arm and arm64
xen/arm: set the system time in Xen via the XENPF_settime hypercall
arch/arm/Kconfig
>>> On 02.11.15 at 18:12, wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1223,7 +1223,7 @@ long do_vcpu_op(int cmd, unsigned int vcpuid,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> if ( v->vcpu_info == &dummy_vcpu_info )
> return -EINVAL;
>
> -if (
On 05/11/15 16:57, Stefano Stabellini wrote:
> +case XENPF_settime32:
> +do_settime(op->u.settime32.secs,
> + op->u.settime32.nsecs,
> + op->u.settime32.system_time);
> +break;
I don't think you want to provide this hypercall -- only provide
This document is going to explain the design details of Xen booting with
ACPI on ARM. Any comments are welcome.
Changes v5->v6:
* add a new node "uefi" under /hypervisor to pass UEFI informations to
Dom0 instead of the nodes under /chosen.
* change creation of MADT table, get the information fro
Remove dummy arm implementation of wallclock_time.
Use shared_info() in common code rather than x86-ism to access it.
Signed-off-by: Stefano Stabellini
Signed-off-by: Ian Campbell
---
xen/arch/arm/time.c |5 ---
xen/arch/x86/time.c | 92 +
x
> static void xen_percpu_init(void)
> {
> struct vcpu_register_vcpu_info info;
> @@ -104,6 +120,8 @@ static void xen_percpu_init(void)
> BUG_ON(err);
> per_cpu(xen_vcpu, cpu) = vcpup;
>
> + xen_setup_runstate_info(cpu);
Does the runstate memory area get unregsitered when
Call update_domain_wallclock_time at domain initialization.
Signed-off-by: Stefano Stabellini
Signed-off-by: Ian Campbell
---
xen/arch/arm/Makefile |1 +
xen/arch/arm/domain.c |3 ++
xen/arch/arm/platform_hypercall.c | 62 +
Hi all,
this small series enables the wallclock time on arm and it consists
mostly in code movement from x86 to common.
Stefano Stabellini (2):
xen: move wallclock functions from x86 to common
arm: export platform_op XENPF_settime
xen/arch/arm/Makefile |1 +
xen/arc
Hi,
> +static u64 get64(const u64 *p)
> +{
> + u64 ret;
> +
> + if (BITS_PER_LONG < 64) {
> + u32 *p32 = (u32 *)p;
> + u32 h, l;
> +
> + /*
> + * Read high then low, and then make sure high is
> + * still the same; this will onl
>>> On 02.11.15 at 17:29, wrote:
> * steal_for_cache may now be wrong. I realize that since now ram == 0
> that all the subsequent "steal_for_cache" expressions will end up as
> "false" anyway, but leaving invariants in an invalid state is sort of
> asking for trouble.
>
> I'd prefer you just up
How can this be missing? Things compile fine now, right? So please
better explain why we do this change.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
> -Original Message-
> From: win-pv-devel-boun...@lists.xenproject.org [mailto:win-pv-devel-
> boun...@lists.xenproject.org] On Behalf Of Lars Kurth
> Sent: 05 November 2015 15:21
> To: Xen-devel; mirageos-devel; xen-...@lists.xenproject.org; Win-pv-
> de...@lists.xenproject.org
> Subject:
On 5 Nov 2015, at 15:21, Lars Kurth wrote:
>
> Hi all,
>
> I wanted to do quick straw-poll regarding Hackathon Locations for next year.
> Before I do this though, I wanted to let you know that the 2016 Developer
> Summit will most likely be in Berlin in October (I am in the process of
> final
On Thu, Nov 05, 2015 at 02:07:26PM +, Hao, Xudong wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: Wednesday, November 4, 2015 6:19 PM
> > To: Hao, Xudong
> > Cc: Wei Liu ; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] ovmf fail to compile
>
On Thu, Nov 05, 2015 at 03:21:18PM +, Lars Kurth wrote:
> Hi all,
>
> I wanted to do quick straw-poll regarding Hackathon Locations for next
> year. Before I do this though, I wanted to let you know that the 2016
> Developer Summit will most likely be in Berlin in October (I am in the
> proces
Rename the count_pgtables hook of the domain builder to alloc_pgtables
and do the allocation of the guest memory for page tables inside this
hook. This will remove the need for accessing the x86 specific pgtables
member of struct xc_dom_image in the generic domain builder code.
Signed-off-by: Juer
pygrub (in identify_disk_image()) detects a DOS style partition table
via the presence of the 0xaa55 signature at the end of the first
sector of the disk.
However this signature is also present in whole-disk configurations
when there is an MBR on the disk. Many filesystems (e.g. ext[234])
include
Support of an unmapped initrd is indicated by the kernel of the domain
via elf notes. In order not to have to use raw elf data in the tools
for support of an unmapped initrd add a flag to the parsed data area
to indicate the kernel supporting this feature.
Switch using this flag in the hypervisor
The Xen hypervisor supports starting a dom0 with large memory (up to
the TB range) by not including the initrd and p2m list in the initial
kernel mapping. Especially the p2m list can grow larger than the
available virtual space in the initial mapping.
The started kernel is indicating the support o
Reorganize struct xc_dom_image to contain a pointer to domain builder
architecture specific private data. This will abstract the architecture
or domain type specific data from the general used data.
The new area is allocated as soon as the domain type is known.
Signed-off-by: Juergen Gross
Acked
Move some data private to the x86 domain builder to the private data
section. Remove extra_pages as they are used nowhere.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
tools/libxc/include/xc_dom.h | 8
tools/libxc/xc_dom_x86.c | 48 +--
flight 63567 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63567/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 6 xen-boot fail REGR. vs. 62277
test-amd64-i386-qemuu-r
In order to prepare a p2m list outside of the initial kernel mapping
do a rework of the domain builder's page table handler. The goal is
to be able to use common helpers for page table allocation and setup
for initial kernel page tables and page tables mapping the p2m list.
This is achieved by supp
In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't waste precious virtual space for the initrd,
but allocate only guest physical memory for it.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
tools/libxc/include/xc_dom.h | 5 +
tools/libxc/xc_dom_co
Carve out the p2m list allocation from the .alloc_magic_pages hook of
the domain builder in order to prepare allocating the p2m list outside
of the initial kernel mapping. This will be needed to support loading
domains with huge memory (>512 GB).
Signed-off-by: Juergen Gross
Acked-by: Ian Campbel
In case the kernel of a new pv-domU indicates it is supporting a p2m
list outside the initial kernel mapping by specifying INIT_P2M, let
the domain builder allocate the memory for the p2m list from physical
guest memory only and map it to the address the kernel is expecting.
This will enable loadi
Guest memory allocation in the domain builder of libxc is done via
virtual addresses only. In order to be able to support preallocated
areas not virtually mapped reorganize the memory allocator to keep
track of allocated pages globally and in allocated segments.
This requires an interface change o
On 03/11/15 12:41, Jan Beulich wrote:
On 03.11.15 at 11:57, wrote:
>> On 03/11/15 07:21, Jan Beulich wrote:
>> On 30.10.15 at 16:36, wrote:
On 30/10/15 13:16, Jan Beulich wrote:
On 30.10.15 at 13:50, wrote:
>> El 14/10/15 a les 16.37, Jan Beulich ha escrit:
>>
On Wed, Nov 4, 2015 at 6:31 AM, Chun Yan Liu wrote:
> Ian & George, any comments?
Hey Chunyan,
I did actually spend a chunk of time looking at this last week.
Looking at the diff-of-diffs, it looks like you've addressed
everything I asked you to address. I still want to take a longer look
at it
On 05/11/15 12:26, Razvan Cojocaru wrote:
> On 11/05/2015 01:44 PM, Andrew Cooper wrote:
>> On 05/11/15 11:35, Andrei LUTAS wrote:
>>> The use-case is the following: whenever an EPT violation is triggered
>>> inside a monitored VM, the introspection logic needs to know how many
>>> bytes were acces
Hi Malcolm,
If you can post the updated patches, that would be great. I think it
would be better for me to test with your update.
Thanks again.
On 11/05/2015 10:20 AM, Malcolm Crossley wrote:
On 05/11/15 13:48, Marcos E. Matsunaga wrote:
Hi Malcolm,
I tried your patches against staging yes
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Wednesday, November 4, 2015 6:19 PM
> To: Hao, Xudong
> Cc: Wei Liu ; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] ovmf fail to compile
>
> On Wed, Nov 04, 2015 at 08:27:56AM +, Hao, Xudong wrote:
> > "git
On 04/11/15 16:17, Jan Beulich wrote:
On 04.11.15 at 17:05, wrote:
>> El 03/11/15 a les 13.41, Jan Beulich ha escrit:
>> On 03.11.15 at 11:57, wrote:
On 03/11/15 07:21, Jan Beulich wrote:
On 30.10.15 at 16:36, wrote:
>> On 30/10/15 13:16, Jan Beulich wrote:
>>
On Thu, 2015-11-05 at 03:49 -0700, Jan Beulich wrote:
> > > > On 05.11.15 at 04:01, wrote:
> > flight 63540 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/63540/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests whic
On 05/11/15 13:48, Marcos E. Matsunaga wrote:
> Hi Malcolm,
>
> I tried your patches against staging yesterday and as soon as I started a
> guest, it panic. I have
> lock_profile enabled and applied your patches against:
I tested with a non debug version of Xen (because I was analysing the
perf
Signed-off-by: Stefano Stabellini
Acked-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk
CC: konrad.w...@oracle.com
---
Changes in v10:
- rebase
---
arch/x86/xen/time.c | 76 +
drivers/xen/Makefile |2 +-
drivers/xen/time.c| 91 +++
Hi all,
I dusted off this series from Jan 2014. Patch #2 and #3 still need an ack.
This patch series introduces stolen ticks accounting for Xen on ARM and
ARM64. Stolen ticks are clocksource ticks that have been "stolen" from
the cpu, typically because Linux is running in a virtual machine and
Introduce CONFIG_PARAVIRT and PARAVIRT_TIME_ACCOUNTING on ARM64.
Necessary duplication of paravirt.h and paravirt.c with ARM.
The only paravirt interface supported is pv_time_ops.steal_clock, so no
runtime pvops patching needed.
This allows us to make use of steal_account_process_tick for stolen
On 11/05/2015 04:05 PM, Andrew Cooper wrote:
> On 05/11/15 12:26, Razvan Cojocaru wrote:
>> On 11/05/2015 01:44 PM, Andrew Cooper wrote:
>>> On 05/11/15 11:35, Andrei LUTAS wrote:
The use-case is the following: whenever an EPT violation is triggered
inside a monitored VM, the introspectio
Introduce CONFIG_PARAVIRT and PARAVIRT_TIME_ACCOUNTING on ARM.
The only paravirt interface supported is pv_time_ops.steal_clock, so no
runtime pvops patching needed.
This allows us to make use of steal_account_process_tick for stolen
ticks accounting.
Signed-off-by: Stefano Stabellini
Acked-by:
Add include asm/paravirt.h to cputime.c, as steal_account_process_tick
calls paravirt_steal_clock, which is defined in asm/paravirt.h.
The ifdef CONFIG_PARAVIRT is necessary because not all archs have an
asm/paravirt.h to include.
Signed-off-by: Stefano Stabellini
CC: mi...@redhat.com
CC: pet...
Register the runstate_memory_area with the hypervisor.
Use pv_time_ops.steal_clock to account for stolen ticks.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- don't use paravirt_steal_rq_enabled: we do not support retrieving
stolen ticks for vcpus other than one we are running on.
Chan
Hi all,
I wanted to do quick straw-poll regarding Hackathon Locations for next year.
Before I do this though, I wanted to let you know that the 2016 Developer
Summit will most likely be in Berlin in October (I am in the process of
finalising space, budget and contract details which will need to
At 13:47 + on 02 Nov (1446472041), Wei Liu wrote:
> So I propose we use the following scheme:
>
> - 6 months release cycle from unstable branch.
> - 4 months development.
> - 2 months freeze.
> - Eat into next cycle if doesn't release on time.
> - Fixed cut-off date: the Fridays of the w
Try to use "xen-qemuuser-domid$domid" first, then
"xen-qemuuser-shared" and root if everything else fails.
The uids need to be manually created by the user or, more likely, by the
xen package maintainer.
Expose a device_model_user setting in libxl_domain_build_info, so that
opinionated callers, s
On Tue, 3 Nov 2015, Ian Campbell wrote:
> On Tue, 2015-11-03 at 16:49 +, Ian Campbell wrote:
> > On Mon, 2015-11-02 at 12:30 +, Stefano Stabellini wrote:
> > > Try to use "xen-qemudepriv-domid$domid" first, then
> > > "xen-qemudepriv-shared" and root if everything else fails.
> > >
> > > Th
As soon as the cache is disabled, it will become out-of-sync with the
VGA device model and since no mechanism exists to acquire current VRAM
state from the device model, re-enabling it leads to stale data
being seen by the guest.
The problem was introduced by commit 3bbaaec0 ("x86/hvm: unify stdvg
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 05 November 2015 12:32
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Keir (Xen.org); Jan Beulich
> Subject: Re: [PATCH] x86/hvm: make sure stdvga cache cannot be re-
> enabled
>
> On 05/11/15 1
On 05/11/15 12:17, Paul Durrant wrote:
> As soon as the cache is disabled, it will become out-of-sync with the
> VGA device model and since no mechanism exists to acquire current VRAM
> state from the device model, re-enabling it leads to stale data
> being seen by the guest.
>
> The problem can be
On 11/05/2015 01:44 PM, Andrew Cooper wrote:
> On 05/11/15 11:35, Andrei LUTAS wrote:
>> The use-case is the following: whenever an EPT violation is triggered
>> inside a monitored VM, the introspection logic needs to know how many
>> bytes were accessed (read/written). This is done by inspecting t
As soon as the cache is disabled, it will become out-of-sync with the
VGA device model and since no mechanism exists to acquire current VRAM
state from the device model, re-enabling it leads to stale data
being seen by the guest.
The problem can be seen by deliberately crashing a Windows guest; th
1 - 100 of 134 matches
Mail list logo
