Hi Paul,
I guess this patch got the summer conference period treatment. ACK,
NACK, completely STUPID idea?
cheers,
daniel
On 10/15/2015 01:32 PM, Daniel Wagner wrote:
> The cpu hotplug state machine in smpboot.c is reusing the states from
> cpu.h. That is confusing when it comes to the CPU_DEAD_
>>> On 04.11.15 at 18:06, wrote:
> Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
> set_xen_guest_handle_raw"):
>> On 04.11.15 at 17:50, wrote:
>> > If we don't provide a get_xen_guest_handle, a kernel developer will be
>> > sorely tempted to make one.
>>
>> What use wou
>>> On 05.11.15 at 02:34, wrote:
> On Wed, Nov 04, 2015 at 10:04:33AM -0700, Jan Beulich wrote:
>> >>> On 03.11.15 at 07:27, wrote:
>> > @@ -158,6 +334,20 @@ void xsave(struct vcpu *v, uint64_t mask)
>> > ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET] = word_size;
>> > }
>> > +#define XSTATE_FIXU
On 2015-11-05 00:13, Boris Ostrovsky wrote:
On 11/04/2015 03:02 PM, Sander Eikelenboom wrote:
On 2015-11-04 19:47, Stephen Smalley wrote:
On 11/04/2015 01:28 PM, Sander Eikelenboom wrote:
On 2015-11-04 16:52, Stephen Smalley wrote:
On 11/04/2015 06:55 AM, Sander Eikelenboom wrote:
Hi All,
I
Hi Ian,
On 3 November 2015 at 23:22, Ian Campbell wrote:
> On Tue, 2015-11-03 at 22:57 +0800, Fu Wei wrote:
>> Hi Vladimir,
>>
>> After discussing with Ian Campbell, Since we already can load all
>> the necessary binaries for Xen boot on arm64 for now, we don't really
>> need "xen_module" comm
Hello,
I need to get the XSAVE size from userspace. The easiest way seems to be
to use the XEN_DOMCTL_getvcpuextstate hypercall, but that hypercall is
not public / there's no xenctrl.h wrapper for it.
There's also struct hvm_hw_cpu_xsave, which I can get to, but it doesn't
have a size member:
54
flight 38249 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38249/
Perfect :-)
All tests in this flight passed
baseline version:
flight 38221
jobs:
build-amd64 pass
build-armhf
On Thu, Nov 05, 2015 at 02:06:25AM -0700, Jan Beulich wrote:
> >>> On 05.11.15 at 02:34, wrote:
> > On Wed, Nov 04, 2015 at 10:04:33AM -0700, Jan Beulich wrote:
> >> >>> On 03.11.15 at 07:27, wrote:
> >> > @@ -158,6 +334,20 @@ void xsave(struct vcpu *v, uint64_t mask)
> >> > case 4: case 2:
>>> 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 extending alternative_input() accordingly
(or provide a second, more flex
>>> On 03.11.15 at 07:27, wrote:
> @@ -640,6 +640,14 @@ static void vmx_save_msr(struct vcpu *v, struct hvm_msr
> *ctxt)
> }
>
> vmx_vmcs_exit(v);
> +
> +if ( cpu_has_xsaves )
> +{
> +ctxt->msr[ctxt->count].val = v->arch.hvm_vcpu.msr_xss;
> +if ( ctxt->msr[ctxt
>>> On 04.11.15 at 23:21, wrote:
>> +int xsplice_perform_rela(struct xsplice_elf *elf,
>> + struct xsplice_elf_sec *base,
>> + struct xsplice_elf_sec *rela)
>> +{
>> +Elf64_Rela *r;
>> +int symndx, i;
>
> unsigned int
>
>> +uint64_t val
>>> On 03.11.15 at 19:16, wrote:
> --- a/xen/include/xen/elfstructs.h
> +++ b/xen/include/xen/elfstructs.h
> @@ -348,6 +348,27 @@ typedef struct {
> #define ELF64_R_TYPE(info) ((info) & 0x)
> #define ELF64_R_INFO(s,t)(((s) << 32) + (u_int32_t)(t))
>
> +/* x86-64 relocatio
>>> On 05.11.15 at 10:52, wrote:
> I need to get the XSAVE size from userspace. The easiest way seems to be
> to use the XEN_DOMCTL_getvcpuextstate hypercall, but that hypercall is
> not public / there's no xenctrl.h wrapper for it.
Before going into any detail of the rest of your mail - any reas
On 11/05/2015 12:42 PM, Jan Beulich wrote:
On 05.11.15 at 10:52, wrote:
>> I need to get the XSAVE size from userspace. The easiest way seems to be
>> to use the XEN_DOMCTL_getvcpuextstate hypercall, but that hypercall is
>> not public / there's no xenctrl.h wrapper for it.
>
> Before going
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 memory to be patched. This can be determined dynamically
+ via symbols or via virtual
>>> 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 which could not be run:
> test-amd64-amd64-xl-qemut-winxpsp3 6 xen-boot
On 05/11/15 10:42, Jan Beulich wrote:
On 05.11.15 at 10:52, wrote:
>> I need to get the XSAVE size from userspace. The easiest way seems to be
>> to use the XEN_DOMCTL_getvcpuextstate hypercall, but that hypercall is
>> not public / there's no xenctrl.h wrapper for it.
> Before going into any
>>> On 05.11.15 at 11:49, wrote:
> On 05/11/15 10:42, Jan Beulich wrote:
> On 05.11.15 at 10:52, wrote:
>>> I need to get the XSAVE size from userspace. The easiest way seems to be
>>> to use the XEN_DOMCTL_getvcpuextstate hypercall, but that hypercall is
>>> not public / there's no xenctrl.h
>>> On 05.11.15 at 11:47, wrote:
> On 11/05/2015 12:42 PM, Jan Beulich wrote:
> On 05.11.15 at 10:52, wrote:
>>> I need to get the XSAVE size from userspace. The easiest way seems to be
>>> to use the XEN_DOMCTL_getvcpuextstate hypercall, but that hypercall is
>>> not public / there's no xenc
On 05/11/15 10:47, Razvan Cojocaru wrote:
> On 11/05/2015 12:42 PM, Jan Beulich wrote:
> On 05.11.15 at 10:52, wrote:
>>> I need to get the XSAVE size from userspace. The easiest way seems to be
>>> to use the XEN_DOMCTL_getvcpuextstate hypercall, but that hypercall is
>>> not public / there's
flight 63569 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63569/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. vs.
63212
Tests whic
On Thu, Nov 05, 2015 at 03:28:47AM -0700, Jan Beulich wrote:
> >>> On 03.11.15 at 07:27, wrote:
> > @@ -640,6 +640,14 @@ static void vmx_save_msr(struct vcpu *v, struct
> > hvm_msr *ctxt)
> > }
> >
> > vmx_vmcs_exit(v);
> > +
> > +if ( cpu_has_xsaves )
> > +{
> > +ctxt
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,
+ * performing relocations, etc.
+ */
+#ifdef CONFIG_X86
+static void *alloc_module(siz
On 11/03/2015 10:18 AM, Borislav Petkov wrote:
From: Borislav Petkov
paravirt_patch_ignore() is completely unused and paravirt_patch_nop()
doesn't do a whole lot. Remove them both.
Signed-off-by: Borislav Petkov
Reviewed-by: Juergen Gross
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Chris
flight 63578 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63578/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340
Tests which did not succe
On 11/5/2015 12:51 PM, Jan Beulich wrote:
On 05.11.15 at 11:49, wrote:
On 05/11/15 10:42, Jan Beulich wrote:
On 05.11.15 at 10:52, wrote:
I need to get the XSAVE size from userspace. The easiest way seems to be
to use the XEN_DOMCTL_getvcpuextstate hypercall, but that hypercall is
not public
As defined by the Xen public header the fifth value of
shutdown_reason is watchdog.
Signed-off-by: Simon Rowe
---
tools/ocaml/libs/xc/xenctrl.ml |2 +-
tools/ocaml/libs/xc/xenctrl.mli |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/
On 05/11/15 11:35, Andrei LUTAS wrote:
> On 11/5/2015 12:51 PM, Jan Beulich wrote:
> On 05.11.15 at 11:49, wrote:
>>> On 05/11/15 10:42, Jan Beulich wrote:
>>> On 05.11.15 at 10:52, wrote:
> I need to get the XSAVE size from userspace. The easiest way seems
> to be
> to use th
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
@@ -3,6 +3,25 @@
#include
#include
+#define PATCH_INSN_SIZE 5
+
+void xsplice_apply
On 11/05/2015 10:35 AM, Jan Beulich wrote:
On 04.11.15 at 23:21, wrote:
+int xsplice_perform_rela(struct xsplice_elf *elf,
+ struct xsplice_elf_sec *base,
+ struct xsplice_elf_sec *rela)
+{
+Elf64_Rela *r;
+int symndx, i;
unsigned int
On 11/05/2015 10:38 AM, Jan Beulich wrote:
On 03.11.15 at 19:16, wrote:
--- a/xen/include/xen/elfstructs.h
+++ b/xen/include/xen/elfstructs.h
@@ -348,6 +348,27 @@ typedef struct {
#define ELF64_R_TYPE(info) ((info) & 0x)
#define ELF64_R_INFO(s,t) (((s) << 32) + (u_int
> On 5 Nov 2015, at 11:39, Simon Rowe wrote:
>
> As defined by the Xen public header the fifth value of
> shutdown_reason is watchdog.
I’ve always been a bit suspicious about having both “Poweroff” and “Halt”
there. Perhaps there was some confusion between what could be written to
‘control/sh
El 19/10/15 a les 17.48, Jan Beulich ha escrit:
On 02.10.15 at 17:48, wrote:
>> @@ -1176,6 +1177,190 @@ int arch_set_info_guest(
>> #undef c
>> }
>>
>> +/* Called by VCPUOP_initialise for HVM guests. */
>> +int arch_set_info_hvm_guest(struct vcpu *v, vcpu_hvm_context_t *ctx)
>
> const ..
>>> On 05.11.15 at 12:51, wrote:
> On 11/05/2015 10:35 AM, Jan Beulich wrote:
> On 04.11.15 at 23:21, wrote:
+int xsplice_perform_rela(struct xsplice_elf *elf,
+ struct xsplice_elf_sec *base,
+ struct xsplice_elf_sec *rela)
+
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
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
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
> -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
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
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
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
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
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
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
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...
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:
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 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
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
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 +++
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
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 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:
>>
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
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
> -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 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 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:
>>
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
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 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
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
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
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 +--
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
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
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
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
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
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 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 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
> -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:
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
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 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
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
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
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 +
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
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
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
>>> 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 (
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
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
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
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..
>>> 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
> @@
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 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
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
> ---
>
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
>>> 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
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 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
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 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
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 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
1 - 100 of 134 matches
Mail list logo
