Hi Vitaly,
On 2016/9/5 17:42, Vitaly Kuznetsov wrote:
> Julien Grall writes:
>
>> Hi Vitaly,
>>
>> On 26/07/16 13:30, Vitaly Kuznetsov wrote:
>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>> particular, when we crash on a secondary vCPU we may want to do kdump
>>> and unl
flight 100798 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100798/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit2 6 xen-boot fail in 100780 pass in 100798
test-armhf-armhf-xl-rtds 11
This run is configured for baseline tests only.
flight 67669 linux-3.14 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67669/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 4 host-ping-
flight 100789 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100789/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 9 debian-di-installfail REGR. vs. 100773
test-armhf-armhf-x
This patch implemented parts of TODO left in commit id
a902c12ee45fc9389eb8fe54eeddaf267a555c58. It moved TLB-flush filtering out
into populate_physmap. Because of TLB-flush in alloc_heap_pages, it's very
slow to create a guest with memory size of more than 100GB on host with
100+ cpus.
This patch
flight 100801 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100801/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ad8a2f5e68fd9850c10740a6ace2ab785cb99818
baseline version:
ovmf 960d0de80b288c7cd9cbc
flight 100800 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100800/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 100796 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100796/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 960d0de80b288c7cd9cbccfde7a12a48935055b4
baseline version:
ovmf ec68dc28557925e0708d5
On Tue, Sep 06, 2016 at 07:25:23PM +0100, Andrew Cooper wrote:
> On 06/09/16 18:22, Konrad Rzeszutek Wilk wrote:
> > On Tue, Aug 23, 2016 at 10:22:12PM -0400, Konrad Rzeszutek Wilk wrote:
> >> From: Ross Lagerwall
> >>
> >> Add hook functions which run during patch apply and patch revert.
> >> Hoo
flight 100786 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100786/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 99786
Tests which did n
This run is configured for baseline tests only.
flight 67668 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67668/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ec68dc28557925e0708d5676288ad140651a3851
baseline v
This run is configured for baseline tests only.
flight 67666 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67666/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 6 xen-boot
This run is configured for baseline tests only.
flight 67667 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67667/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-pvgrub 10 guest-start
flight 100784 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100784/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 100573
test-amd64-amd64-xl-qemuu-win
Ravi Sahita's dynamically allocated altp2m structs
Signed-off-by: Paul Lai
Reviewed-by: Ravi Sahita
---
xen/arch/x86/hvm/hvm.c| 8 +++---
xen/arch/x86/hvm/vmx/vmx.c| 2 +-
xen/arch/x86/mm/altp2m.c | 16 +--
xen/arch/x86/mm/mem_sharing.c | 2 +-
xen/arch/x86/mm/mm-loc
Indent goto labels by one space
Inline (header) altp2m functions
Define default behavior in switch
Define max and min for range of altp2m macroed values
Signed-off-by: Paul Lai
---
xen/arch/x86/hvm/hvm.c| 46 ---
xen/include/asm-x86/hvm/hvm.h | 19
Move altp2m specific functions to altp2m files. This makes the code
a little easier to read.
Also moving ept code to ept specific files as requested in:
https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html
Signed-off-by: Paul Lai
---
xen/arch/x86/mm/altp2m.c |
From: Jan Beulich
Consistently consult hvm_cpuid(). With that, BNDCFGS gets better
handled outside of VMX specific code, just like XSS. Don't needlessly
check for MTRR support when the MSR being accessed clearly is not an
MTRR one.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
xen
On Wed, 7 Sep 2016, Andrew Cooper wrote:
> On 07/09/2016 22:02, Stefano Stabellini wrote:
> > On Wed, 7 Sep 2016, Meng Xu wrote:
> >> On Wed, Sep 7, 2016 at 3:08 PM, Stefano Stabellini
> >> wrote:
> >>> On Wed, 7 Sep 2016, Ian Jackson wrote:
> > Technical
> > =
> > On the techn
Incorporating comments generated by v3 patch series.
Older comments, reason for the code clean effort, are the following URLs:
https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html
https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04454.html
https://list
On 09/07/2016 10:56 PM, Stefano Stabellini wrote:
On Wed, 7 Sep 2016, Paulina Szubarczyk wrote:
Copy data operated on during request from/to local buffers to/from
the grant references.
Before grant copy operation local buffers must be allocated what is
done by calling ioreq_init_copy_buffers.
On 07/09/2016 22:02, Stefano Stabellini wrote:
> On Wed, 7 Sep 2016, Meng Xu wrote:
>> On Wed, Sep 7, 2016 at 3:08 PM, Stefano Stabellini
>> wrote:
>>> On Wed, 7 Sep 2016, Ian Jackson wrote:
> Technical
> =
> On the technical front, it would be good to understand whether
>
On Wed, 7 Sep 2016, Meng Xu wrote:
> On Wed, Sep 7, 2016 at 3:08 PM, Stefano Stabellini
> wrote:
> >
> > On Wed, 7 Sep 2016, Ian Jackson wrote:
> > > > Technical
> > > > =
> > > > On the technical front, it would be good to understand whether
> > > > a) This is a real threat and whether th
On Wed, 7 Sep 2016, Paulina Szubarczyk wrote:
> Copy data operated on during request from/to local buffers to/from
> the grant references.
>
> Before grant copy operation local buffers must be allocated what is
> done by calling ioreq_init_copy_buffers. For the 'read' operation,
> first, the qemu
On Wed, Sep 7, 2016 at 3:08 PM, Stefano Stabellini
wrote:
>
> On Wed, 7 Sep 2016, Ian Jackson wrote:
> > > Technical
> > > =
> > > On the technical front, it would be good to understand whether
> > > a) This is a real threat and whether thus, we as a community need to
> > >take action
Adding Lenovo.
On 09/07/2016 02:59 PM, Boris Ostrovsky wrote:
> ACPI builder is currently distributed under GPLv2 license.
>
> We plan to make the builder available to components other
> than the hvmloader (which is also GPLv2). Some of these
> components (such as libxl) may be distributed under L
On Wed, 7 Sep 2016, Ian Jackson wrote:
> > Technical
> > =
> > On the technical front, it would be good to understand whether
> > a) This is a real threat and whether thus, we as a community need to
> >take action
>
> It is unclear what action the Xen upstream community can usefully
Provide ability to load multiple ACPI modules. Thie feature is needed
by PVHv2 guests and will be used in subsequent patches.
We assume that PVHv2 guests do not load their ACPI modules specified
in the configuration file. We can extend support for that in the future
if desired.
Signed-off-by: Bor
Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
---
tools/firmware/hvmloader/acpi/build.c | 70 ++---
tools/firmware/hvmloader/acpi/libacpi.h | 1 +
tools/firmware/hvmloader/util.c | 2 +-
3 files changed, 40 insertions(+), 33 deletions(-)
diff --
Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
---
Changes in v3:
* Broke "if ( !waet ) return -1;" line
tools/firmware/hvmloader/acpi/build.c | 10 +++---
tools/firmware/hvmloader/acpi/libacpi.h | 1 +
tools/firmware/hvmloader/util.c | 2 +-
3 files changed, 9 insertio
PVHv2 guests may request LAPIC emulation (and nothing else)
Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
---
xen/arch/x86/domain.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7ca1
Add entry for ACPI tables created for PVHv2 guests to e820 map.
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* format adjustments
tools/libxl/libxl_dom.c | 8
tools/libxl/libxl_x86.c | 15 +++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/tools/libxl
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Now that we don't have x86.h define LAPIC_BASE_ADDRESS in libxl_arch.h
tools/libxl/Makefile | 2 ++
tools/libxl/libxl_arch.h | 6 ++
tools/libxl/libxl_dom.c | 19 +++
3 files changed, 23 insertions(+), 4 deletions(-)
Users other than hvmloader may provide TIS address as virtual.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
---
tools/firmware/hvmloader/acpi/build.c | 9 -
tools/firmware/hvmloader/acpi/libacpi.h | 3 +++
tools/firmware/hvmloader/config.h | 2 ++
tools/firmware/hvmlo
libxl__domain_make() may want to use b_info so we should set defaults
a little earlier.
Signed-off-by: Boris Ostrovsky
---
tools/libxl/libxl_create.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Some constification of call parameters
* Format adjustments
* New acpi_mem_free hook (a nop)
* Changes in init_acpi_config() to deal with constified acpi_numa's
pointers (initialize pointers as temp variabales)
* Add '-include acpi' directive i
Intermediate stages of building a target should be made with
temporary files that are copied to final target in the end.
Signed-off-by: Boris Ostrovsky
---
New in v3
tools/libacpi/Makefile | 39 +++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --gi
Load ACPI modules into guest space
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Use more macros in first_high_idx intilalization.
* Format adjustments
tools/libxc/xc_dom_core.c | 93 +++
1 file changed, 93 insertions(+)
diff --git a/tools/libx
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
---
MAINTAINERS| 1 +
tools/firmware/hvmloader/Makefile | 14 --
tools/firmware/hvmloader/ovmf.c| 2 +-
tools/firmware/rombios/3
No need for ACPI code to rely on hvm_info variable.
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Constified acpi_numa's pointers
* Constified acpi_config call parameter where possible
tools/firmware/hvmloader/acpi/build.c | 51 +
tools/firmware/hvmloader
ACPI builder is currently distributed under GPLv2 license.
We plan to make the builder available to components other
than the hvmloader (which is also GPLv2). Some of these
components (such as libxl) may be distributed under LGPL-2.1
so that they can be used by non-GPLv2 callers. But this
will no
Non-hvmloader users may be building tables in virtual address space
and therefore we need to make sure that values that end up in tables
are physical addresses.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
---
tools/firmware/hvmloader/acpi/build.c | 47 ++-
PVH guests require DSDT with only ACPI INFO (Xen-specific) and Processor
objects. We separate ASL's ACPI INFO definition into dsdt_acpi_info.asl so
that it can be included in ASLs for both HVM and PVH2.
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Added comment to dsdt_acpi_info.asl indica
ACPI sources will be available to various component which will build
them according to their own rules. ACPI's Makefile will only generate
necessary source files.
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Replace '(shell pwd) with CURDIR
* More use of addprefix
.gitignore
Components that wish to use ACPI builder will need to provide their own
mem_alloc() and virt_to_phys() routines. Pointers to these routines will
be passed to the builder as memory ops.
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Constified more function call parameters
* Added a free() no
The goal here is to build ACPI tables for PVHv2/HVMlite guests while reusing
existing
hvmloader's ACPI builder code. The builder is provided as a library in
tools/libacpi.
This is version 3 of the series, see individual patches for changes. It can
be fetched from git://oss.oracle.com/git/bostrov
In prepearation to moving acpi sources into generally available
libacpi:
1. Pass IOAPIC/LAPIC/PCI mask values via struct acpi_config
2. Modify include files search paths to point to acpi directory
3. Macro-ise include file for build.c that defines various
utilities used by that file. Users of l
flight 100780 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100780/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 100756
Regressions which
flight 100783 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100783/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ec68dc28557925e0708d5676288ad140651a3851
baseline version:
ovmf 96c13c011766a950247c7
flight 100782 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100782/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-s
New CPU hotplug framework was introduced recently. These patches convert Xen
CPU hotplug code to this infrastructure.
The patches (patch 1 specifically) will apply on top of
https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg00562.html
v2: Changes in patch 1 suggested by Sebastian
From: Sebastian Andrzej Siewior
Install the callbacks via the state machine.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Boris Ostrovsky
---
drivers/xen/events/events_fifo.c | 34 --
include/linux/cpuhotplug.h | 1 +
2 files changed, 13 inser
Switch to new CPU hotplug infrastructure.
Signed-off-by: Boris Ostrovsky
Suggested-by: Sebastian Andrzej Siewior
---
Changes in v2:
* Replace xen_cpu_up_cancel with xen_cpu_dead
* Use existing CPUHP_AP_ONLINE_DYN instead of introducing new state
* Be more careful with return value of cpuhp_setup
On Wed, Sep 07, 2016 at 12:41:00PM +0200, Paulina Szubarczyk wrote:
> Copy data operated on during request from/to local buffers to/from
> the grant references.
>
> Before grant copy operation local buffers must be allocated what is
> done by calling ioreq_init_copy_buffers. For the 'read' operati
On 07/09/16 16:33, Ian Jackson wrote:
> Lars Kurth writes ("Impact of HW vulnerabilities & Implications on Security
> Vulnerability Process"):
>> A few years ago it was discovered that much of the RAM shipped in our
>> computers contains flaws which allow "leakage" across rows; effectively
>> allo
>>> On 07.09.16 at 11:12, wrote:
> Currently it is only possible to set mem_access restrictions only for
> a contiguous range of GFNs (or, as a particular case, for a single GFN).
> This patch introduces a new libxc function taking an array of GFNs.
> The alternative would be to set each page in t
On 07/09/16 16:33, Ian Jackson wrote:
> Lars Kurth writes ("Impact of HW vulnerabilities & Implications on Security
> Vulnerability Process"):
>> A few years ago it was discovered that much of the RAM shipped in our
>> computers contains flaws which allow "leakage" across rows; effectively
>> allo
From 2b4e942ad75f4a4546c417d8bd1116e3af368daf Mon Sep 17 00:00:00 2001
From: Charles Arnold
Date: Wed, 7 Sep 2016 09:48:18 -0600
Subject: [PATCH] tools: fix vif-route add|remove
vif-route is called twice. First for the vif interface and
second for the vif-emu interface. vif-route takes 4 paramete
>>> On 07.09.16 at 17:33, wrote:
> Lars Kurth writes ("Impact of HW vulnerabilities & Implications on Security
> Vulnerability Process"):
>> c) Whether there is any mitigation that we can develop, if necessary
>
> AIUI there is little to be done. But, I look forward to being proven
> wrong.
We
flight 100779 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100779/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-winxpsp3 17 guest-start/win.repeat fail in 100771
pass in 100779
test-armhf-armhf-
Lars Kurth writes ("Impact of HW vulnerabilities & Implications on Security
Vulnerability Process"):
> A few years ago it was discovered that much of the RAM shipped in our
> computers contains flaws which allow "leakage" across rows; effectively
> allowing programs to use access to one bit of mem
On Wed, Sep 07, 2016 at 11:43:27AM +0100, Julien Grall wrote:
>
>
> On 07/09/2016 04:33, Konrad Rzeszutek Wilk wrote:
> > > ...snip..
> > > > > +case R_AARCH64_ABS32:
> > > > > +ovf = reloc_data(RELOC_OP_ABS, dest, val, 32);
> > > > > +break;
> > > >
> > > > I hav
Dear community members,
A few years ago it was discovered that much of the RAM shipped in our
computers contains flaws which allow "leakage" across rows; effectively
allowing programs to use access to one bit of memory to flip bits in
other parts of memory to which they have been specifically deni
On Wed, Sep 7, 2016 at 3:12 AM, Razvan Cojocaru
wrote:
> Currently it is only possible to set mem_access restrictions only for
> a contiguous range of GFNs (or, as a particular case, for a single GFN).
> This patch introduces a new libxc function taking an array of GFNs.
> The alternative would be
Jan Beulich writes ("[PATCH v2] libelf: drop pointless uses of __FUNCTION__"):
> Non-debugging message text should be (and is in the cases here, albeit
> often only with the addition of an ELF: prefix) distinguishable without
> also logging function names.
>
> In the messages touched at once use %
Hi Konrad,
On 07/09/2016 15:13, Konrad Rzeszutek Wilk wrote:
On Wed, Sep 07, 2016 at 01:50:43PM +0100, Julien Grall wrote:
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 8ee5a11..0ca97b9 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -99,
On Wed, Sep 07, 2016 at 01:50:44PM +0100, Julien Grall wrote:
> With livepatch the alternatives that should be patched are outside of
> the Xen hypervisor _start -> _end. The current code is assuming that
> only Xen could be patched and therefore will explode when a payload
> contains alternatives.
On Wed, Sep 07, 2016 at 01:50:43PM +0100, Julien Grall wrote:
> This patch contains only renaming and comment update. There are no
> functional changes:
> - Don't mix _start and _stext, they both point to the same address
> but the former makes more sense (we are mapping the Xen binary, not
>>> On 07.09.16 at 09:59, wrote:
> Non-debugging message text should be (and is in the cases here, albeit
> often only with the addition of an ELF: prefix) distinguishable without
> also logging function names.
>
> In the messages touched at once use %#x (or variants thereof) in favor
> of 0x%x.
>>> On 07.09.16 at 14:05, wrote:
> On Mon, Sep 05, 2016 at 06:33:57AM -0600, Jan Beulich wrote:
>> >>> On 20.08.16 at 00:43, wrote:
>> > +static char __initdata *ebmalloc_free = NULL;
>> > +
>> > +/* EFI boot allocator. */
>> > +static void __init *ebmalloc(size_t size)
>> > +{
>> > +void *pt
On Wed, 2016-09-07 at 14:24 +0100, anshul makkar wrote:
> On 05/09/16 15:55, Dario Faggioli wrote:
> > On Thu, 2016-09-01 at 11:52 +0100, anshul makkar wrote:
> > So, yes, we know already that it's running in a cpu at least from
> > its
> > hard affinity, what is it exactly that you are not underst
On 05/09/16 15:55, Dario Faggioli wrote:
On Thu, 2016-09-01 at 11:52 +0100, anshul makkar wrote:
On 17/08/16 18:19, Dario Faggioli wrote:
+/*
+ * We're doing soft-affinity, and we know that the current
vcpu on cpu
+ * has a soft affinity. We now want to know whether cpu itself
is i
flight 100791 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100791/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
Hi Vitaly,
On 07/09/2016 12:23, Vitaly Kuznetsov wrote:
BTW, were you able to try the patch I suggested? In my opinion it would
be preferable to fix the immediate SMP issue now and play with MPIDR
info later.
Not yet sorry. I will see if I can try to today or tomorrow.
Cheers,
--
Julien Gral
On 05/09/16 14:26, Dario Faggioli wrote:
On Thu, 2016-09-01 at 12:08 +0100, anshul makkar wrote:
On 17/08/16 18:19, Dario Faggioli wrote:
Can't we
just read their workload or we can change the locktype to allow
reading ?
Reading without taking the lock would race against the load value bein
Hi,
The first patch is a clean-up added in this new version. The second contains the
meat of this series.
Yours sincerely,
Julien Grall (2):
xen/arm: alternative: Clean-up __apply_alternatives
xen/arm: alternative: Make it possible to patch outside of the
hypervisor
xen/arch/arm/altern
With livepatch the alternatives that should be patched are outside of
the Xen hypervisor _start -> _end. The current code is assuming that
only Xen could be patched and therefore will explode when a payload
contains alternatives.
Given that alt_instr contains a relative offset, the function
__appl
This patch contains only renaming and comment update. There are no
functional changes:
- Don't mix _start and _stext, they both point to the same address
but the former makes more sense (we are mapping the Xen binary, not
only the text section).
- s/text_mfn/xen_mfn/ and s/text_orde
On 05/09/16 14:47, Dario Faggioli wrote:
On Wed, 2016-08-31 at 18:10 +0100, anshul makkar wrote:
On 17/08/16 18:18, Dario Faggioli wrote:
@@ -1266,6 +1272,7 @@ csched2_alloc_vdata(const struct scheduler
*ops, struct vcpu *vc, void *dd)
ASSERT(svc->sdom != NULL);
svc->cred
On Mon, Sep 05, 2016 at 06:33:57AM -0600, Jan Beulich wrote:
> >>> On 20.08.16 at 00:43, wrote:
[...]
> > +static char __initdata *ebmalloc_free = NULL;
> > +
> > +/* EFI boot allocator. */
> > +static void __init *ebmalloc(size_t size)
> > +{
> > +void *ptr;
> > +
> > +/*
> > + * In
flight 100777 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100777/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt 3 host-install(3) broken in 100770 pass in 100777
test-amd64-amd64-i386-pvgrub
Hi Konrad,
On 07/09/2016 04:06, Konrad Rzeszutek Wilk wrote:
---
xen/arch/arm/alternative.c | 58 +-
1 file changed, 31 insertions(+), 27 deletions(-)
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 8ee5a11..db4bd0f 100644
Julien Grall writes:
> Hi Vitaly,
>
> On 07/09/2016 10:07, Vitaly Kuznetsov wrote:
>> Stefano Stabellini writes:
>>> I don't know that much about cpuid, but the virtual MPIDR is constructed
>>> from the vcpu id right now:
>>>
>>> v->arch.vmpidr = MPIDR_SMP | vcpuid_to_vaffinity(v->vcpu_id);
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: 07 September 2016 11:49
> To: Paul Durrant ; George Dunlap
>
> Cc: xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] missing unplug of SCSI devices in HVM guest
>
> Am 7. September 2016 12:38:09 MESZ, schrieb Paul D
Am 7. September 2016 12:38:09 MESZ, schrieb Paul Durrant
:
>I would have thought option #1 is the most logical and desirable in the
>long run, but #2 could perhaps be used (by means of a configuration
>option to qemu) in the meantime. In practice I doubt there is anything
>out there that would us
On 07/09/2016 04:33, Konrad Rzeszutek Wilk wrote:
...snip..
+case R_AARCH64_ABS32:
+ovf = reloc_data(RELOC_OP_ABS, dest, val, 32);
+break;
I have noticed that not all the relocations are implemented (e.g
R_AARCH64_ABS16, R_AARCH64_MOVW_*...). I don't think the
Copy data operated on during request from/to local buffers to/from
the grant references.
Before grant copy operation local buffers must be allocated what is
done by calling ioreq_init_copy_buffers. For the 'read' operation,
first, the qemu device invokes the read operation on local buffers
and on
Hi Konrad,
On 07/09/2016 01:31, Konrad Rzeszutek Wilk wrote:
+void arch_livepatch_apply_jmp(struct livepatch_func *func)
+{
+uint32_t insn;
+uint32_t *old_ptr;
+uint32_t *new_ptr;
+
+BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque));
+BUILD_BUG_ON(PATCH_INSN_SIZE != sizeof
flight 100788 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100788/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen d6be2cfccfffd6d5ff1da68277ec3ab13e595368
baseline version:
xen 158d
In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..)
system call is invoked. In mini-os the operation is yet not
implemented. For the OSs that does not implement gnttab the
call of the grant copy operation causes abort.
Signed-off-by: Paulina Szubarczyk
Reviewed-by: David Vrabel
---
t
Hi,
It is a proposition for implementation of grant copy operation in qemu-qdisk
and interface in libxc/libs.
Changes since v5:
-added checking of every interface in the configure file. Based on
the Roger's comment that xengnttab_map_grant_ref was added prior
xengnttab_grant_copy, thus do not
> -Original Message-
> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
> George Dunlap
> Sent: 06 September 2016 17:42
> To: Olaf Hering ; Paul Durrant
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] missing unplug of SCSI devices in HVM guest
>
> On Wed, Aug 24,
>>> On 07.09.16 at 07:59, wrote:
> On 09/07/16 02:31, Tamas K Lengyel wrote:
>> Just a quick update on this issue, I also now see the following
>> emulation error when I use xen-access with the emulation response for
>> the exec case. The issue previously reported with the failed vm entry
>> seem
Hi Vitaly,
On 07/09/2016 10:07, Vitaly Kuznetsov wrote:
Stefano Stabellini writes:
I don't know that much about cpuid, but the virtual MPIDR is constructed
from the vcpu id right now:
v->arch.vmpidr = MPIDR_SMP | vcpuid_to_vaffinity(v->vcpu_id);
[...]
static inline register_t vc
flight 100773 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100773/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 100738
test-amd64-i386-xl-qemuu-wi
>>> On 07.09.16 at 10:28, wrote:
> On Wed, Sep 07, 2016 at 12:02:33AM -0700, Dongli Zhang wrote:
>> > But since what Dongli cares about at the moment is domain creation, it
>> > certainly won't hurt to limit this optimization to domain creation time;
>> > then we can discuss enabling it for balloo
>>> On 06.09.16 at 18:51, wrote:
> --- a/xen/common/livepatch_elf.c
> +++ b/xen/common/livepatch_elf.c
> @@ -86,7 +86,16 @@ static int elf_resolve_sections(struct livepatch_elf *elf,
> const void *data)
> delta < sizeof(Elf_Ehdr) ? "at ELF header" : "is past
> end");
>
Currently it is only possible to set mem_access restrictions only for
a contiguous range of GFNs (or, as a particular case, for a single GFN).
This patch introduces a new libxc function taking an array of GFNs.
The alternative would be to set each page in turn, using a userspace-HV
roundtrip for ea
On 07/09/16 10:07, Vitaly Kuznetsov wrote:
> Stefano Stabellini writes:
>
>> On Tue, 6 Sep 2016, Vitaly Kuznetsov wrote:
>>> Stefano Stabellini writes:
>>>
On Mon, 5 Sep 2016, Vitaly Kuznetsov wrote:
> Julien Grall writes:
>
>> Hi Vitaly,
>>
>> On 26/07/16 13:30, Vitaly
Stefano Stabellini writes:
> On Tue, 6 Sep 2016, Vitaly Kuznetsov wrote:
>> Stefano Stabellini writes:
>>
>> > On Mon, 5 Sep 2016, Vitaly Kuznetsov wrote:
>> >> Julien Grall writes:
>> >>
>> >> > Hi Vitaly,
>> >> >
>> >> > On 26/07/16 13:30, Vitaly Kuznetsov wrote:
>> >> >> It may happen that
1 - 100 of 128 matches
Mail list logo
