>>> On 08.04.16 at 14:18, wrote:
> The SMEP/SMAP series is still very concerning. I need to follow up on
> the performance testing, but it currently looks like no real improvement
> on the 40-70% performance hit for 32bit PV guests.
Well, we didn't really expect much of a change for 32-bit guest
>>> On 24.03.16 at 17:48, wrote:
> There are a number of debugging options for Xen so the idea is to have a
> menu to group them all together.
>
> Signed-off-by: Doug Goldstein
> ---
> This is more of an RFC than a merge request. If this seems reasonable I'll
> add all the other debugging option
>>> On 25.03.16 at 22:02, wrote:
> On 3/25/16 2:49 PM, Konrad Rzeszutek Wilk wrote:
>> On Thu, Mar 24, 2016 at 11:48:19AM -0500, Doug Goldstein wrote:
>>> --- a/xen/Kconfig.debug
>>> +++ b/xen/Kconfig.debug
>>> @@ -4,3 +4,14 @@ menuconfig DEBUG
>>> ---help---
>>> If you want to debug Xen
>>> On 09.04.16 at 01:24, wrote:
On 25.03.16 at 22:02, wrote:
>> On 3/25/16 2:49 PM, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Mar 24, 2016 at 11:48:19AM -0500, Doug Goldstein wrote:
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -4,3 +4,14 @@ menuconfig DEBUG
---he
>>> On 09.04.16 at 16:42, wrote:
> On Thu, Apr 07, 2016 at 09:38:53AM -0600, Jan Beulich wrote:
>> >>> On 07.04.16 at 05:05, wrote:
>> >> >> > +/* All CPUs are waiting, now signal to disable IRQs. */
>> >> >&
>>> On 10.04.16 at 21:47, wrote:
> That allows the size and offsets to be the same. I checked under ARM32
> builds:
>
>
> struct xsplice_patch_func_internal {
> const char * name; /* 0 4 */
> uint32_t _pad0;/* 4
>>> On 10.04.16 at 04:45, wrote:
> On Sat, Apr 09, 2016 at 10:36:00PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Thu, Apr 07, 2016 at 09:43:38AM -0600, Jan Beulich wrote:
>> > >>> On 07.04.16 at 05:09, wrote:
>> > >> > +uint8_t *old_ptr;
&
>>> On 11.04.16 at 16:22, wrote:
> Konrad Rzeszutek Wilk writes ("Re: REST MAINTAINERS feedback requested
> Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall
> mirroring XENVER_ but sane."):
>> On Mon, Apr 11, 2016 at 11:50:25AM +0100, Ian Jackson wrote:
>> > I don't think
>>> On 09.04.16 at 02:37, wrote:
> On Fri, Apr 08, 2016 at 04:50:10PM -0600, Jan Beulich wrote:
>> >>> On 09.04.16 at 00:45, wrote:
>> > On Fri, Apr 08, 2016 at 03:18:09PM -0600, Jan Beulich wrote:
>> >> >>> On 08.04.16 at 23:10,
>>> On 11.04.16 at 17:50, wrote:
> On Mon, Apr 11, 2016 at 09:44:55AM -0600, Jan Beulich wrote:
>> >>> On 10.04.16 at 21:47, wrote:
>> > That allows the size and offsets to be the same. I checked under ARM32
>> > builds:
>> >
>> >
>>> On 10.04.16 at 16:28, wrote:
> On April 05, 2016 5:48pm, Jan Beulich wrote:
>> >>> On 01.04.16 at 16:47, wrote:
>> > +{
>> > +ASSERT(pdev->domain);
>> > +list_del(&
ioreq server, writes will inevitably be trapped into hypervisor,
>>>> which means significant performance impact.
>>>>
>>>> Also note that this HVMOP_map_mem_type_to_ioreq_server will not
>>>> change the p2m type of any guest ram page, until HVMOP_
>>> On 11.04.16 at 13:14, wrote:
> On 4/9/2016 6:28 AM, Jan Beulich wrote:
>>>>> On 31.03.16 at 12:53, wrote:
>>> @@ -168,13 +226,72 @@ static int hvmemul_do_io(
>>> break;
>>> case X86EMUL_UNHANDLEABL
>>> On 11.04.16 at 05:27, wrote:
> On April 11, 2016 11:10am, wrote:
>> On March 29, 2016 3:37pm, Jan Beulich wrote:
>> > >>> On 25.03.16 at 10:27, wrote:
>> > > On March 18, 2016 6:20pm, wrote:
>> > >> >>> On 17
>>> On 11.04.16 at 18:34, wrote:
> On Mon, Apr 11, 2016 at 12:03:49PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Mon, Apr 11, 2016 at 09:53:06AM -0600, Jan Beulich wrote:
>> > >>> On 09.04.16 at 02:37, wrote:
>> > > On Fri, Apr 08, 2016 at 04:
>>> On 11.04.16 at 18:25, wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
> [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
> XENVER_ but sane."):
>> On 11.04.16 at 16:22, wrote:
>> > But to a
>>> On 11.04.16 at 18:53, wrote:
> On Mon, Apr 11, 2016 at 05:25:04PM +0100, Ian Jackson wrote:
>> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
>> Certainly if
>> we are going to permit these strings etc. to be bigger than fits in
>
>>> On 11.04.16 at 16:04, wrote:
> @@ -5964,6 +5976,10 @@ void destroy_xen_mappings(unsigned long s, unsigned
> long e)
> unsigned int i;
> unsigned long v = s;
>
> +/* Set of valid PTE bits which may be altered. */
> +#define FLAGS_MASK (_PAGE_NX|_PAGE_RW|_PAGE_PRESENT)
> +n
>>> On 11.04.16 at 19:08, wrote:
> If the system admin continously tried to unload and load the patchset
> then we certainly would spam.
>
> But the 'loading' is (or ought to) be a single event. The applying
> or reverting may be done more often.
>
> As such I would say that the operations that
>>> On 11.04.16 at 19:13, wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
> [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
> XENVER_ but sane."):
>> On 11.04.16 at 18:25, wrote:
>> > But a
>>> On 11.04.16 at 19:13, wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
> [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
> XENVER_ but sane."):
>> On 11.04.16 at 18:25, wrote:
>> > But a
ng
> _PAGE_PRESENT to modify_xen_mappings().
>
> As cleanup (and an ideal functional test), the boot logic which remaps Xen's
> code and data with reduced permissions is altered to use
> modify_xen_mappings(), rather than map_pages_to_xen() passing the same mfn's
> back in.
>
>>> Tamas K Lengyel 04/11/16 9:47 PM >>>
>--- a/xen/include/public/vm_event.h
>+++ b/xen/include/public/vm_event.h
>@@ -166,6 +166,31 @@ struct vm_event_regs_x86 {
>uint32_t _pad;
>};
>
>+struct vm_event_regs_arm {
>+uint32_t r0;
>+uint32_t r1;
>+uint32_t r2;
>+uint32_t r3;
>>> "Yu, Zhang" 04/12/16 11:47 AM >>>
>On 4/12/2016 12:31 AM, Jan Beulich wrote:
>>>>> On 11.04.16 at 13:14, wrote:
>>> On 4/9/2016 6:28 AM, Jan Beulich wrote:
>>>>>>> On 31.03.16 at 12:53, wrote:
>>>>>
>>> George Dunlap 04/12/16 11:58 AM >>>
>On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich wrote:
>>> ISTM that the lower duplication (which in principle is an advantage
>>> which will be time limited if we are ever able to completely remove
>>> teh ol
>>> George Dunlap 04/12/16 4:38 PM >>>
>On Tue, Apr 12, 2016 at 2:56 PM, Konrad Rzeszutek Wilk
> wrote:
>> options (1-4) seem perfectly fine to me. FWIW my preferred color
>> would probably be 1 because it's the easiest and least inconsistent
>> with the current state of things. My least favorit
>>> Ian Jackson 04/12/16 6:47 PM >>>
>George Dunlap writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested
>Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_
>>but sane."):
>> Well we know which option Andy prefers, but are there other options
>> that Andy is n
>>> Julien Grall 04/13/16 6:01 PM >>>
>--- a/xen/include/xen/bitops.h
>+++ b/xen/include/xen/bitops.h
>@@ -3,6 +3,17 @@
>#include
>
>/*
>+ * Create a contiguous bitmask starting at bit position @l and ending at
>+ * position @h. For example
>+ * GENMASK_ULL(39, 21) gives us the 64bit vector 0x
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>-/* If we are done with the L2E, check if it is now empty. */
>-if ( (v != e) && (l1_table_offset(v) != 0) )
>+/*
>+ * If we not destroying mappings, or are not done with the L2E,
>+ * skip
e feasible
>in other arches.
>
>Signed-off-by: Roger Pau Monné
>Requested-by: Jan Beulich
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> Razvan Cojocaru 04/13/16 7:53 PM >>>
>LOCK-prefixed instructions are currenly allowed to run in parallel
>in x86_emulate(), which can lead the guest into an undefined state.
>This patch fixes the issue.
... by ... (read: Too brief a description)
>--- a/xen/arch/x86/hvm/emulate.c
>+++ b/xen/a
>>> Julien Grall 04/14/16 10:55 AM >>>
>On 14/04/2016 05:01, Jan Beulich wrote:
>>>>> Julien Grall 04/13/16 6:01 PM >>>
>>> --- a/xen/include/xen/bitops.h
>>> +++ b/xen/include/xen/bitops.h
>>> @@ -3,6 +3,17 @@
>>
>>> Andrew Cooper 04/14/16 5:14 PM >>>
>On 14/04/16 15:26, Konrad Rzeszutek Wilk wrote:
>> @@ -312,8 +307,8 @@ struct xsplice_patch_func {
>> };
>>
>>
>> -The size of the structure is 64 bytes or 52 bytes if compiled under 32-bit
>> -hypervisors.
>> +The size of the structure is 64 bytes on
>>> Razvan Cojocaru 04/14/16 11:37 AM >>>
>On 04/13/2016 06:05 PM, Tamas K Lengyel wrote:
>>
>> Yea, well then we need to introduce a new struct with a new subop to
>> pass the bitmask. I guess its a lesson in ABI design to leave some
>> wiggle room for future-proofing it (my bad). So I guess we
>>> Julien Grall 04/14/16 5:08 PM >>>
>On 14/04/16 15:56, Jan Beulich wrote:
>>>>> Julien Grall 04/14/16 10:55 AM >>>
>>> On 14/04/2016 05:01, Jan Beulich wrote:
>>>>>>> Julien Grall 04/13/16 6:01 PM >>>
>
>>> Razvan Cojocaru 04/14/16 10:50 AM >>>
>On 04/14/2016 07:35 AM, Jan Beulich wrote:
>>> --- a/xen/arch/x86/hvm/emulate.c
>>> >+++ b/xen/arch/x86/hvm/emulate.c
>>> >@@ -25,6 +25,8 @@
>> >#include
>> >#include
>>
>>> Razvan Cojocaru 04/14/16 11:08 AM >>>
>On 04/14/2016 08:56 AM, Razvan Cojocaru wrote:
--- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -112,6 +112,7 @@
>>> > >#include
>>> > >#include
>>> > >#include
>> +#include
>>> >
>>> > This header shouldn't be include
>>> Razvan Cojocaru 04/14/16 1:43 PM >>>
>On 04/14/2016 01:35 PM, David Vrabel wrote:
>> On 13/04/16 13:26, Razvan Cojocaru wrote:
>>> LOCK-prefixed instructions are currenly allowed to run in parallel
>>> in x86_emulate(), which can lead the guest into an undefined state.
>>> This patch fixes the
>>>> Razvan Cojocaru 04/14/16 7:57 AM >>>
>On 04/14/16 07:35, Jan Beulich wrote:
>>>>> Razvan Cojocaru 04/13/16 7:53 PM >>>
>>> @@ -1589,6 +1591,8 @@ x86_emulate(
>> >}
>> >done_prefixes:
>&g
>>> George Dunlap 04/14/16 5:16 PM >>>
>On the other hand, I think there's a bit of a faulty interpretation of
>the procedure here. Jan reviewed the patch thoroughly and then acked
>it; on the basis of that, Konrad legitimately checked it in. After it
>was checked in Jan said, "I've changed my m
>>> Razvan Cojocaru 04/14/16 5:45 PM >>>
>On 04/14/2016 06:40 PM, Jan Beulich wrote:
>> To be honest, just having remembered that we do the write back for locked
>> instructions using CMPXCHG, I'd first of all like to see a proper description
>> of &qu
>>> Andrew Cooper 04/14/16 5:46 PM >>>
>Short of having the instruction emulator convert any locked instruction
>into a stub, I can't think of a solution which works for both emulated
>and non-emulated instructions.
That's my understanding too.
Jan
_
>>> Razvan Cojocaru 04/14/16 6:00 PM >>>
>On 04/14/2016 06:44 PM, Jan Beulich wrote:
>> That's the performance effect on the hypervisor you talk about. But what
>> about
>> the guest, which all of the sudden gets another domain wide lock app
onrad Rzeszutek Wilk
Requested-and-acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> Konrad Rzeszutek Wilk 04/14/16 12:05 AM >>>
> @@ -460,6 +461,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
> u_sysctl)
> ret = tmem_control(&op->u.tmem_op);
> break;
>
> +case XEN_SYSCTL_xsplice_op:
> +ret = xsplice_op(&op->u.xsplice);
> +copyb
;+ */
Stray empty comment line.
>--- /dev/null
>+++ b/xen/include/xen/virtual_region.h
>@@ -0,0 +1,47 @@
>+/*
>+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
>+ *
>+ */
>+
>+#ifndef __XEN_VIRTUAL_REGION__
>>> George Dunlap 04/14/16 6:20 PM >>>
>On Thu, Apr 14, 2016 at 4:59 PM, Jan Beulich wrote:
>>>>> George Dunlap 04/14/16 5:16 PM >>>
>>>On the other hand, I think there's a bit of a faulty interpretation of
>>>the procedure h
>>> Ian Jackson 04/14/16 8:12 PM >>>
>Jan Beulich writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:
>> And btw., considering that Konrad has already posted a revert patch,
>> and I have ack-ed that one, this could now go in right away (and the
>>> George Dunlap 04/15/16 1:23 PM >>>
>On Thu, Apr 14, 2016 at 6:01 PM, Jan Beulich wrote:
>>>Sure, mistakes happen; but I hope it's not being to controversial to
>>>say that in general, the procedure should be arranged such that the
>>>perso
>>> Ben Sanda 04/14/16 10:03 PM >>>
>>> +void put_pg_owner(struct domain *pg_owner) {
>>> +rcu_unlock_domain(pg_owner);
>>> +}
> I cannot see why this then can't just become an inline function.
>
>I investigated this but making put_pg_owner() static inline creates a
>circular dependency on rcu
>>> Konrad Rzeszutek Wilk 04/15/16 2:55 AM >>>
>On Thu, Apr 14, 2016 at 09:17:14AM -0600, Jan Beulich wrote:
>> >>> Andrew Cooper 04/14/16 5:14 PM >>>
>> >On 14/04/16 15:26, Konrad Rzeszutek Wilk wrote:
>> >> @@ -312,8 +307,8 @@
>>> Konrad Rzeszutek Wilk 04/15/16 4:29 AM >>>
>On Thu, Apr 14, 2016 at 10:36:46AM -0600, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk 04/14/16 12:05 AM >>>
>> > @@ -460,6 +461,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_
>>> Andrew Cooper 04/15/16 7:12 PM >>>
>On 08/04/16 13:10, Jan Beulich wrote:
>> http://lists.xen.org/archives/html/xen-devel/2016-03/msg02167.html
>> (with the 1st patch having gone in already)
>
>Apologies for the delay on this. I now have results in.
>
>>> Roger Pau Monne 04/15/16 8:29 PM >>>
>I've also noticed that Xen always sets "-no-integrated-as" when using clang,
>because previous versions (<3.8.0) didn't support .code16/.code32/.code64
>in inline asm. This is solved at least in version 3.8.0 (haven't tested
>older versions). The problem n
>>> Roger Pau Monne 04/15/16 8:27 PM >>>
>Previously HOSTCC was always hardcoded to gcc
So what is the goal here? Be able to build on a gcc-free system? Or else, how
does it matter what compiler build elements get built with?
>--- a/Config.mk
>+++ b/Config.mk
>@@ -36,7 +36,6 @@ CONFIG_$(XEN_OS)
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>Signed-off-by: Konrad Rzeszutek Wilk
>Suggested-by: Jan Beulich
>Acked-by: Julien Grall [ARM]
>Reviewed-by: Andrew Cooper
Is that really the case? I think it was Andrew who suggested to not expose a
second vari
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>+static int elf_verify_strtab(const struct xsplice_elf_sec *sec)
>+{
>+ const Elf_Shdr *s;
>+ const uint8_t *contents;
Considering it's a string table, perhaps better const char *?
>+ s = sec->sec;
>+
>+ if ( s->sh_type != SHT_STRTAB )
>+ return -
>>> Konrad Rzeszutek Wilk 04/14/16 12:04 AM >>>
>--- a/xen/arch/x86/Makefile
>+++ b/xen/arch/x86/Makefile
>@@ -64,6 +64,7 @@ obj-y += vm_event.o
>obj-y += xstate.o
>
>obj-$(crash_debug) += gdbstub.o
>+obj-$(CONFIG_XSPLICE) += xsplice.o
This should be added in the main section, somewhere ahea
>>> Konrad Rzeszutek Wilk 04/18/16 7:55 AM >>>
>> >+ if ( delta > elf->len )
>> >+ {
>> >+ dprintk(XENLOG_ERR, XSPLICE "%s: Section table is past end of payload!\n",
>> >+ elf->name);
>> >+ return -EINVAL;
>> >+ }
>> >+
>> >+ for ( i = 1; i < elf->hdr->e_shnum; i++ )
>> >+ {
>> >+ delta = elf->hdr
>>> Konrad Rzeszutek Wilk 04/18/16 9:50 AM >>>
>On Sun, Apr 17, 2016 at 02:05:10AM -0600, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk 04/15/16 4:29 AM >>>
>> >On Thu, Apr 14, 2016 at 10:36:46AM -0600, Jan Beulich wro
>>> Paul Durrant 04/18/16 10:41 AM >>>
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 April 2016 22:48
>> >>> On 31.03.16 at 12:53, wrote:
>> > --- a/xen/include/public/hvm/hvm_op.h
>> > +++ b/xen/includ
>>> Razvan Cojocaru 04/18/16 2:40 PM >>>
>On 04/14/2016 07:08 PM, Jan Beulich wrote:
>>>>> Razvan Cojocaru 04/14/16 5:45 PM >>>
>>> On 04/14/2016 06:40 PM, Jan Beulich wrote:
>>>> To be honest, just having remembered that we do th
>>> Paul Durrant 04/18/16 6:45 PM >>>
>The original patch was posted before the cut-off IIRC so I'm not sure
> of the policy regarding freeze-exceptions.
It was submitted before the feature freeze, yes, but didn't make it in by
code freeze. So it's my understanding that an exception would be ne
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>--- a/docs/misc/xsplice.markdown
>+++ b/docs/misc/xsplice.markdown
>@@ -289,8 +289,13 @@ describing the functions to be patched:
>
>struct xsplice_patch_func {
>const char *name;
>+#if BITS_PER_LONG == 32
>+uint32_t new_addr;
>+
>>> Razvan Cojocaru 04/19/16 1:01 PM >>>
>I think this might be because the LOCK prefix should guarantee that the
>instruction that follows it has exclusive use of shared memory (for both
>reads and writes) but I might be misreading the docs:
LOCK definitely has no effect on other than the instru
>>> "Yu, Zhang" 04/19/16 1:46 PM >>>
>On 4/19/2016 7:15 PM, Paul Durrant wrote:
>> I talked to Wei earlier and he is happy to give a freeze exception to this
>> change.
>
>Great! I really obliged. :)
>BTW, Does some form of application need to be submitted? I'm not
>familiar with the procedure.
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>--- a/xen/arch/arm/Makefile
>+++ b/xen/arch/arm/Makefile
>@@ -57,6 +57,8 @@ ifeq ($(CONFIG_ARM_64),y)
>ln -sf $(notdir $@) ../../$(notdir $@).efi
>endif
>
>+tests:
I think this should be phony just like ...
>--- a/xen/arch/x86/Makefile
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>--- a/xen/arch/x86/test/xen_hello_world.c
>+++ b/xen/arch/x86/test/xen_hello_world.c
>@@ -10,11 +10,14 @@
>static char hello_world_patch_this_fnc[] = "xen_extra_version";
>extern const char *xen_hello_world(void);
>
>+/* External symbol. */
>+ext
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>NEW CODE:
>
>To make that work we add three tables:
Why three? Two (or a single one with element pairs) ought to be sufficient:
Afaict you could just have (symbol-address,symbol-offset) pairs which you
then sort and search by name (using symbols_ex
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>@@ -331,16 +332,23 @@ static char *pointer(char *str, char *end, const char
>**fmt_ptr,
>{
>unsigned long sym_size, sym_offset;
>char namebuf[KSYM_NAME_LEN+1];
>+bool_t payload = 0;
I don't see the point of this var
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>+bool_t is_patch(const void *ptr)
>+{
>+struct payload *data;
You guess it: const.
>+/*
>+ * No locking since this list is only ever changed during apply or revert
>+ * context.
>+ */
What if you crash while applying or revert
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>@@ -48,19 +49,23 @@ static void __init swap_ex(void *a, void *b, int size)
>}
>#endif
>
>-void __init sort_exception_tables(void)
>+void __INIT sort_exception_table(struct exception_table_entry *start,
>+ struct exception_ta
>>> "Xu, Quan" 04/20/16 7:29 AM >>>
>I am still not sure whether we really need throw out error message for each
>IOMMU mapping or not.
>If yes, I will throw out error message for each IOMMU mapping in next v3.
Ideally not, if it's a batch that it failing, The question just is whether at
the po
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>--- a/xen/arch/x86/Makefile
>+++ b/xen/arch/x86/Makefile
>@@ -6,7 +6,11 @@ subdir-y += mm
>subdir-$(CONFIG_XENOPROF) += oprofile
>subdir-y += x86_64
>
>+ifdef CONFIG_XSPLICE
>+obj-y += alternative.o
>+else
>obj-bin-y += alternative.init.o
>+endi
membering that we had agreed for this to live ahead of _erodata?
>@@ -61,6 +66,51 @@ const char *xen_deny(void)
>return "";
>}
>
>+static const void *build_id_p;
>+static unsigned int build_id_len;
__read_mostly? Also these variables are kind of pointless to have in a bui
>}
>+
>+case XENVER_build_id:
>+{
>+xen_build_id_t build_id;
>+unsigned int sz = 0;
>+int rc = 0;
>+const void *p = NULL;
All three initializers seem to be pointless.
With that taken care of,
Acked-by: Jan Beulich
__
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>+.PHONY: note.o
>+note.o:
>+ $(OBJCOPY) -O binary --only-section=.note.gnu.build-id
>$(BASEDIR)/xen-syms $@.bin
>+ $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
>+ --rename-section=.data=.xsplice.depends -S $@.bin
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
Same comments here as for previous test cases.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>--- a/xen/common/xsplice.c
>+++ b/xen/common/xsplice.c
>@@ -517,6 +517,8 @@ static int prepare_payload(struct payload *payload,
>sec = xsplice_elf_sec_by_name(elf, ".note.gnu.build-id");
>if ( sec )
>{
>+struct payload *data;
r message.
>
>Depending on the situation return different error codes in order to
>enable the tools to print useful messages.
>
>Requested-by: Ian Jackson
>Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
___
Xen
>>> Tamas K Lengyel 04/14/16 6:34 PM >>>
>+static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
>+{
>+uint32_t capabilities = 0;
Pointless initializer.
>+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
>+
>+return capabilities;
>+}
Even more - the en
>>> Julien Grall 04/20/16 2:35 PM >>>
>It is a matter of taste.
Indeed.
> Is there any reason to not allow different way to create a mask?
I dislike it, but not so much to stand in the way to get it in. I.e. I'm not
going
to NAK it, but I'm also not currently planning to ACK it.
Jan
___
>>> George Dunlap 04/20/16 6:30 PM >>>
>On Wed, Apr 20, 2016 at 4:02 PM, George Dunlap
>wrote:
>> On 19/04/16 12:02, Yu, Zhang wrote:
>>> So I suppose the only place we need change for this patch is
>>> for hvmmem_type_t, which should be defined like this?
>>>
>>> typedef enum {
>>> HVMMEM_r
>>> Konrad Rzeszutek Wilk 04/20/16 6:09 PM >>>
>On Mon, Apr 18, 2016 at 12:23:26AM -0600, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk 04/18/16 7:55 AM >>>
>> >> >+ if ( delta > elf->len )
>> >> >+ {
>>
>>> Konrad Rzeszutek Wilk 04/20/16 6:00 PM >>>
>> >+ size_t pages; /* Total pages for [text,rw,ro]_addr */
>>
>> Why size_t and not just unsigned int?
>
>Oh. I was somehow under the impression you liked size_t more than
>unsignged int! I will change it over.
When used where actually talking abou
>>> Konrad Rzeszutek Wilk 04/20/16 6:10 PM >>>
>> >+.PHONY: xsplice
>> >+xsplice: config.h
>> >+ # Need to have these done in sequential order
>> >+ $(MAKE) -f $(BASEDIR)/Rules.mk xen_hello_world_func.o
>> >+ $(MAKE) -f $(BASEDIR)/Rules.mk xen_hello_world.o
>>
>> Why do these two need doing
>>> Roger Pau Monné 04/20/16 4:51 PM >>>
>On Sun, Apr 17, 2016 at 02:03:28PM -0600, Jan Beulich wrote:
>> >>> Roger Pau Monne 04/15/16 8:27 PM >>>
>> >@@ -50,8 +49,10 @@ DESTDIR ?= /
>> >clang ?= n
>> >ifeq ($(clang
>>> On 30.03.16 at 09:28, wrote:
> 2016-03-29 18:39 GMT+08:00 Jan Beulich :
>> Forwarding entire batches to the device model when an individual
>> iteration of them got rejected by internal device emulation handlers
>> with X86EMUL_UNHANDLEABLE is wrong: The device
0x110
[] prepare_exit_to_usermode+0xe9/0xf0
[] retint_user+0x8/0x13
This is CVE-2016-3961 / XSA-174.
Reported-by: Vitaly Kuznetsov
Signed-off-by: Jan Beulich
Cc: sta...@vger.kernel.org
---
arch/x86/include/asm/hugetlb.h |1 +
1 file changed, 1 insertion(+)
--- 4.6-rc4/arch/x86/include/asm/hugetlb.h
++
>>> On 20.04.16 at 19:36, wrote:
> On Apr 20, 2016 6:05 PM, "Jan Beulich" wrote:
>>
>> >>> Konrad Rzeszutek Wilk 04/20/16 6:00 PM >>>
>> >> >+ size_t pages; /* Total pages for [text,rw,ro]_addr */
>> >>
>> >
>>> On 21.04.16 at 02:28, wrote:
>> >+ASSERT(sec);
>> >+if ( sec->sec->sh_size % sizeof(*payload->funcs) )
>> >+{
>> >+dprintk(XENLOG_ERR, XSPLICE "%s: Wrong size of .xsplice.funcs!\n",
>> >+elf->name);
>> >+return -EINVAL;
>> >+}
>> >+
>> >+payl
>>> On 21.04.16 at 02:26, wrote:
>> >+unsigned long xsplice_symbols_lookup_by_name(const char *symname)
>> >+{
>> >+struct payload *data;
>>
>> Do you need symbols other than those marked "new_symbol" past the loading
>> of the module? If not, wouldn't it be worthwhile to shrink the symbol ta
>>> On 21.04.16 at 02:29, wrote:
> On Tue, Apr 19, 2016 at 02:17:35PM -0600, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>> >+bool_t is_patch(const void *ptr)
>> >+{
>> >+struct payload *data;
>>
>>> On 21.04.16 at 02:30, wrote:
> On Wed, Apr 20, 2016 at 12:28:02AM -0600, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>> >--- a/xen/arch/x86/Makefile
>> >+++ b/xen/arch/x86/Makefile
>> >@@ -6,7 +6,
>>> On 21.04.16 at 02:31, wrote:
>> >--- a/xen/common/xsplice.c
>> >+++ b/xen/common/xsplice.c
>> >@@ -533,6 +533,39 @@ static int prepare_payload(struct payload *payload,
>> >}
>> >
>> >#ifndef CONFIG_ARM
>> >+sec = xsplice_elf_sec_by_name(elf, ".altinstructions");
>> >+if ( sec )
>>> On 21.04.16 at 02:33, wrote:
> On Wed, Apr 20, 2016 at 01:14:17AM -0600, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>> >--- a/Config.mk
>> >+++ b/Config.mk
>> >@@ -126,6 +126,17 @@ endef
>> &
>>> On 21.04.16 at 07:09, wrote:
> On 04/12/16 16:45, Haozhong Zhang wrote:
>> On 04/08/16 09:52, Jan Beulich wrote:
>> > >>> On 08.04.16 at 07:02, wrote:
>> > > On 03/29/16 04:49, Jan Beulich wrote:
>> > >> >>> On 2
As proposed on the hackathon.
Signed-off-by: Jan Beulich
Acked-by: Ian Jackson
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -437,10 +437,15 @@ F: xen/xsm/
F: docs/misc/xsm-flask.txt
THE REST
+M: Andrew Cooper
+M: George Dunlap
M: Ian Jackson
M: Jan Beulich
M: Keir
(re-adding xen-devel)
>>> On 21.04.16 at 09:48, wrote:
> 2016-04-21 14:24 GMT+08:00 Jan Beulich :
>
>> >>> On 30.03.16 at 09:28, wrote:
>> > 2016-03-29 18:39 GMT+08:00 Jan Beulich :
>> >> Forwarding entire batches to the device model when an
>>> On 20.04.16 at 19:33, wrote:
> * Userspace tooling
>
> Plan to move to xl / libxl. Need to have stable interface in libxl
> Tool is simple now, but might be more complex when sig verification
> is involved.
>
> Jan: use external utility to veirfy, better. Xl should only do basic
> uplo
301 - 400 of 13762 matches
Mail list logo
