> 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 ballooning when someone finds it to
> be an issue.
Thank you all very much for the feedback. The current limitat
On 09/07/16 09:56, Julien Grall wrote:
> Hi Ravzan,
>
> On 06/09/2016 20:16, Razvan Cojocaru wrote:
>> On 09/06/16 22:06, Stefano Stabellini wrote:
>>> On Thu, 28 Jul 2016, Julien Grall wrote:
> The function p2m_set_mem_access can be re-implemented using the
> generic
> functions p2m_g
This run is configured for baseline tests only.
flight 67664 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67664/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 96c13c011766a950247c743887705cc035a15497
baseline v
Hi, Jan,
Thank you very much for reviewing my patches in details! Please
check my comments below.
On 16-09-06 01:40:00, Jan Beulich wrote:
> >>> On 25.08.16 at 07:22, wrote:
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -23,22 +23,116 @@
> > #define PSR_CAT(1<<1)
> >
On 16-09-06 01:43:22, Jan Beulich wrote:
> >>> On 25.08.16 at 07:22, wrote:
>
> Please extend the comments given for patch 1 to this one. Just one
> extra thing:
>
> > @@ -743,7 +744,7 @@ struct xen_sysctl_psr_cat_op {
> > uint32_t cos_max; /* OUT: Maximum COS */
> > #define XEN_
Hi Stefano,
On 06/09/2016 19:21, Stefano Stabellini wrote:
On Tue, 6 Sep 2016, Julien Grall wrote:
Hi Stefano,
On 05/09/16 22:58, Stefano Stabellini wrote:
On Thu, 28 Jul 2016, Julien Grall wrote:
The current implementation of relinquish_p2m_mapping is modifying the
page table to erase the e
flight 100776 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100776/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 99786
Regressi
>>> On 07.09.16 at 07:36, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 02, 2016 6:22 PM
>>
>> 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 w
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.
---
v2: Add a missing ELF: prefix. Further dis
>>> On 06.09.16 at 18:47, wrote:
> On Wed, Aug 24, 2016 at 02:55:21AM -0600, Jan Beulich wrote:
>> >>> On 24.08.16 at 04:22, wrote:
>> > --- a/xen/common/livepatch.c
>> > +++ b/xen/common/livepatch.c
>> > @@ -70,6 +70,9 @@ struct payload {
>> > unsigned int nsyms; /* Nr of e
>>> On 06.09.16 at 18:57, wrote:
> On Wed, Aug 24, 2016 at 02:58:48AM -0600, Jan Beulich wrote:
>> >>> On 24.08.16 at 04:22, wrote:
>> > Livepatch expected at some point to be able to print the
>> > build-id during bootup, which it did not. The reason is
>> > that xen_build_init and livepatch_in
>>> On 06.09.16 at 21:56, wrote:
> On Wed, Aug 24, 2016 at 03:08:01AM -0600, Jan Beulich wrote:
>> >>> On 24.08.16 at 04:22, wrote:
>> > --- a/xen/common/livepatch.c
>> > +++ b/xen/common/livepatch.c
>> > @@ -237,13 +237,34 @@ static const char *livepatch_symbols_lookup(unsigned
>> > long addr,
>>> On 06.09.16 at 22:05, wrote:
> On Wed, Aug 24, 2016 at 03:13:18AM -0600, Jan Beulich wrote:
>> >>> On 24.08.16 at 04:22, wrote:
>> > The NOP functionality will NOP any of the code at
>> > the 'old_addr' or at 'name' if the 'new_addr' is zero.
>> > The purpose of this is to NOP out calls, such
>>> On 06.09.16 at 22:16, wrote:
> On Thu, Aug 25, 2016 at 08:54:51AM -0600, Jan Beulich wrote:
>> >>> On 25.08.16 at 15:37, wrote:
>> > --- a/xen/common/livepatch.c
>> > +++ b/xen/common/livepatch.c
>> > @@ -3,6 +3,7 @@
>> > *
>> > */
>> >
>> > +#include
>> > #include
>> > #include
>>
Hi Stefano,
On 06/09/2016 19:51, Stefano Stabellini wrote:
On Tue, 6 Sep 2016, Julien Grall wrote:
I was asking myself the same question
It is not trivial. On ARMv7, there is no way to invalidate by IPA, so we still
need to do a full flush.
In the case of ARMv8, it is possible to do a flush
Hello,
The fastest way to compile-check the patches that touch ARM bits is to
simply cross-compile, and I've followed the instructions here:
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling#64-bit_crossbuild
However, there was an error trying to build master
>>> On 06.09.16 at 23:18, wrote:
> On Thu, Aug 25, 2016 at 09:11:15AM -0600, Jan Beulich wrote:
>> >>> On 25.08.16 at 15:37, wrote:
>> > --- a/xen/common/livepatch_elf.c
>> > +++ b/xen/common/livepatch_elf.c
>> > @@ -71,7 +71,15 @@ static int elf_resolve_sections(struct livepatch_elf
>> > *elf,
flight 67665 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67665/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like
67613
test-amd64-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, September 07, 2016 3:59 PM
>
> >>> On 07.09.16 at 07:36, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, September 02, 2016 6:22 PM
> >>
> >> Consistently consult hvm_cpuid(). With that, BNDCFGS gets be
>>> On 06.09.16 at 19:16, wrote:
> On Thu, Aug 25, 2016 at 09:05:27AM -0600, Jan Beulich wrote:
>> >>> On 25.08.16 at 15:37, wrote:
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -271,6 +271,7 @@ F: tools/misc/xen-livepatch.c
>> > F: xen/arch/*/livepatch*
>> > F: xen/arch/*/*/livepatc
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 ballooning when someone finds it to
> > be an
On 09/06/2016 05:28 PM, Jan Beulich wrote:
On 06.09.16 at 16:21, wrote:
>> On 09/06/2016 05:07 PM, Jan Beulich wrote:
>> On 06.09.16 at 12:00, wrote:
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1836,6 +1836,15 @@ long p2m_set_mem_access(struct domain *d, gfn_t
>
Hi
I took the time to write a small script which restores and destroys domains
from provided state files.
Just apply the patch to a xen 4.6.1, provide some images + state files and
start the script.
python VmStarter.py -FILE /path/to/domU-0.state -FILE /path/to/domU-1.state
--loggingLevel DEBU
On 09/07/2016 11:36 AM, Razvan Cojocaru wrote:
> On 09/06/2016 05:28 PM, Jan Beulich wrote:
> On 06.09.16 at 16:21, wrote:
>>> On 09/06/2016 05:07 PM, Jan Beulich wrote:
>>> On 06.09.16 at 12:00, wrote:
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1836,6 +1836,1
On 07/09/2016 09:24, Razvan Cojocaru wrote:
Hello,
Hello Razvan,
The fastest way to compile-check the patches that touch ARM bits is to
simply cross-compile, and I've followed the instructions here:
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling#64-
flight 100785 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100785/
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
>> >>> On 25.08.16 at 07:22, wrote:
>> > + struct psr_socket_alloc_info *info);
>> > +/*
>> > + * get_old_set_new is used in set value process to get all features'
>> > + * COS registers values according to original cos id of the domain.
>> > + * Then, assem
>>> On 07.09.16 at 09:13, wrote:
> On 16-09-06 01:43:22, Jan Beulich wrote:
>> >>> On 25.08.16 at 07:22, wrote:
>>
>> Please extend the comments given for patch 1 to this one. Just one
>> extra thing:
>>
>> > @@ -743,7 +744,7 @@ struct xen_sysctl_psr_cat_op {
>> > uint32_t cos_max;
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
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
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 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");
>
>>> 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
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
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
>>> 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
> -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,
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
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 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
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
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
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
> -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
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);
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
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
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
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
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
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
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
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 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
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
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
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 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 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 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 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.
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,
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 %
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
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 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
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
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-
>>> 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
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 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
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
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
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
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
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
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 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
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
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
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
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
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
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 ++-
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
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
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
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
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
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
1 - 100 of 128 matches
Mail list logo
