flight 102138 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102138/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 101909
test-amd64-i386-l
On Fri, Nov 11, 2016 at 03:39:26PM +, Andrew Cooper wrote:
> On 10/11/16 16:06, Jan Beulich wrote:
> > So far we didn't guarantee 16-byte alignment of the stack: While (so
> > far) we don't tell the compiler to use smaller alignment, we also don't
> > guarantee 16-byte alignment when establishi
On Fri, Nov 11, 2016 at 03:33:11PM +, Andrew Cooper wrote:
> On 11/11/16 15:32, Jan Beulich wrote:
> On 11.11.16 at 16:16, wrote:
> >> On Thu, Nov 10, 2016 at 09:50:24AM -0500, Boris Ostrovsky wrote:
> >>> Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
> >>> APIC ID
On Fri, Nov 11, 2016 at 03:36:13PM +, Andrew Cooper wrote:
> On 10/11/16 12:29, Jan Beulich wrote:
> > When introducing support for these instructions, adjustment for the
> > alignment check logic (generating #GP(0)) was overlooked.
> >
> > Signed-off-by: Jan Beulich
>
> Reviewed-by: Andrew C
On Fri, Nov 11, 2016 at 09:21:00AM -0700, Jan Beulich wrote:
> >>> On 11.11.16 at 14:54, wrote:
> > On Thu, Nov 10, 2016 at 05:30:25AM -0700, Jan Beulich wrote:
> >> With us incremementally adding proper CPUID checks to x86_emulate()
> >> (see commit de05bd965a ["x86emul: correct {,F}CMOV and F{,U
flight 102133 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102133/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102111
test-armhf-armhf-libvirt
flight 102117 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102117/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 101909
test-amd64-i386-l
On Tue, Oct 25, 2016 at 11:40:49AM +0800, Yi Sun wrote:
> Signed-off-by: Yi Sun
> ---
> docs/features/l2_cat.pandoc | 314
>
> 1 file changed, 314 insertions(+)
> create mode 100644 docs/features/l2_cat.pandoc
>
> diff --git a/docs/features/l2_cat.p
On Fri, Nov 04, 2016 at 10:51:33PM +0200, Andrushchenko, Oleksandr wrote:
> Signed-off-by: Oleksandr Dmytryshyn
> Signed-off-by: Iurii Konovalenko
> Signed-off-by: Andrushchenko, Oleksandr
> Signed-off-by: Oleksandr Grytsov
> ---
> Changes since v1:
> * removed __attribute__((__packed__)) from
flight 102127 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102127/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ffd6b0b1b65e620816fb16fe551f92309f4b7269
baseline version:
ovmf b1067637cf53fd55f34b6
On Tue, Nov 01, 2016 at 03:57:13PM +0200, Artem Mygaiev wrote:
> Let me explain a bit background of this work.
>
> We see growing amount of use cases for different "co-processors" like
> - GPUs (inside of most modern SoCs)
> - low-power side CPU cores (like ARM Cortex M or R on board with
> Cort
On Fri, 11 Nov 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 10/11/16 20:42, Stefano Stabellini wrote:
> > On Thu, 10 Nov 2016, Julien Grall wrote:
> > > On 10/11/16 00:21, Stefano Stabellini wrote:
> > > > On Fri, 4 Nov 2016, Andre Przywara wrote:
> > > > > On 24/10/16 16:32, Vijay Kilari wrote:
On Sat, Oct 29, 2016 at 10:59:59AM +0200, Roger Pau Monne wrote:
> Introduce a helper to parse the Dom0 kernel.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> Changes since v2:
> - Remove debug messages.
> - Don't hardcode the number of modules to 1.
>
On Sat, Oct 29, 2016 at 10:59:57AM +0200, Roger Pau Monne wrote:
> Current {un}map_mmio_regions implementation has a maximum number of loops to
> perform before giving up and returning to the caller. This is an issue when
> mapping large MMIO regions when building the hardware domain. In order to
>
On Wed, Nov 09, 2016 at 09:39:56AM -0500, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky
> ---
> CC: Paul Durrant
> ---
> Changes in v2:
> * Use 'true/false' values for bools
>
>
> xen/arch/x86/hvm/ioreq.c | 72
>
> 1 file changed, 72
On Wed, Nov 09, 2016 at 09:39:55AM -0500, Boris Ostrovsky wrote:
> PVH guests will have ACPI accesses emulated by the hypervisor
> as opposed to QEMU (as is the case for HVM guests)
>
> Support for IOREQ server emulation of CPU hotplug is indicated
> by XEN_X86_EMU_IOREQ_CPUHP flag.
>
> Logic for
On Wed, Nov 09, 2016 at 09:39:54AM -0500, Boris Ostrovsky wrote:
> This is the method that will get invoked on an SCI.
>
> Signed-off-by: Boris Ostrovsky
> Reviewed-by: Andrew Cooper
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> tools/libacpi/mk_dsdt.c | 10 +-
> 1 file changed, 5 inserti
On Wed, Nov 09, 2016 at 09:39:51AM -0500, Boris Ostrovsky wrote:
> ACPI builder marks VCPUS set in vcpu_online map as enabled in MADT.
> With ACPI-based CPU hotplug we only want VCPUs that are started by
> the guest to be marked as such. Remaining VCPUs will be set to
> "enable" by AML code during
On Wed, Nov 09, 2016 at 09:39:53AM -0500, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> Changes in v2:
> * HVM guests continue having the buttons
>
> tools/firmware/hvmloader/util.c | 3 ++-
> tools/libacpi/build.c | 2 ++
> tools/
On Fri, 11 Nov 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 11/11/2016 02:24, Stefano Stabellini wrote:
> > On Thu, 10 Nov 2016, Julien Grall wrote:
> > > (CC Stefano and change the title)
> > >
> > > Hello,
> > >
> > > On 10/11/16 12:13, casionwoo wrote:
> > > > I’m pleased about your reply a
flight 102111 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102111/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102097
test-armhf-armhf-libvirt
On Fri, 11 Nov 2016, Julien Grall wrote:
> > > The guest should be IPA agnostic and not care how the physical device is
> > > working when using PV drivers. So for me,
> > > this should be fixed in the DOM0 OS.
> > Do you consider driver domain guests?
>
> The main point of driver domain is isolat
On Fri, 11 Nov 2016, Andrii Anisov wrote:
> Hello Julien,
>
> Please see my comments below:
>
> > From my understanding of what you say, the problem is not because domU is
> > using memory above 4GB but the fact that >the backend driver does not take
> > the right decision
>
> Yep, the problem
On Mon, Nov 07, 2016 at 04:07:58PM +0800, Feng Wu wrote:
> PI hook vmx_pi_switch_to() is needed even when any previously
> assigned device is detached from the domain. Since 'SN' bit is
> also used to control the CPU side PI and we change the state of
> SN bit in these two functions, then evaluate
flight 102129 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102129/
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 Mon, Nov 07, 2016 at 04:08:02PM +0800, Feng Wu wrote:
> Use type-safe structure assignment instead of memcpy()
> Use sizeof(*iremap_entry).
>
>
> Signed-off-by: Feng Wu
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> v7:
> - Remove a useless cleanup
>
> v6:
> - More descripion about the patch
>
>>> On 29.10.16 at 10:59, wrote:
> +static int __init hvm_populate_memory_range(struct domain *d, uint64_t start,
> + uint64_t size)
> +{
> +unsigned int order, i = 0;
> +struct page_info *page;
> +int rc;
> +#define MAP_MAX_ITER 64
> +
> +
>>> On 29.10.16 at 10:59, wrote:
> Current {un}map_mmio_regions implementation has a maximum number of loops to
> perform before giving up and returning to the caller. This is an issue when
> mapping large MMIO regions when building the hardware domain. In order to
> solve it, introduce a wrapper
On Fri, Nov 11, 2016 at 09:46:56AM +, Julien Grall wrote:
> Hi Stefano,
>
> On 11/11/2016 02:24, Stefano Stabellini wrote:
> >On Thu, 10 Nov 2016, Julien Grall wrote:
> >>(CC Stefano and change the title)
> >>
> >>Hello,
> >>
> >>On 10/11/16 12:13, casionwoo wrote:
> >>>I’m pleased about your
>>> On 29.10.16 at 10:59, wrote:
> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_build.c
> @@ -191,10 +191,8 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
> }
>
> #ifdef CONFIG_SHADOW_PAGING
> -static bool_t __initdata opt_dom0_shadow;
> +bool __initdata opt_dom0
>>> On 11.11.16 at 17:09, wrote:
> Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
> which is now fired in a one-shot manner when enabled via the new
> VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
> The patch also fixes the behaviour of the xc_hvm_inject_trap()
> hyperca
>>> On 11.11.16 at 14:54, wrote:
> On Thu, Nov 10, 2016 at 05:30:25AM -0700, Jan Beulich wrote:
>> With us incremementally adding proper CPUID checks to x86_emulate()
>> (see commit de05bd965a ["x86emul: correct {,F}CMOV and F{,U}COMI{,P}
>> emulation"]) it is no longer appropriate to invoke the f
flight 102114 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102114/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b1067637cf53fd55f34b6a6147988e06f8cb7e80
baseline version:
ovmf c52f00d6e1e14b9eaf5c5
Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
which is now fired in a one-shot manner when enabled via the new
VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
The patch also fixes the behaviour of the xc_hvm_inject_trap()
hypercall, which would lead to non-architectural in
On 11/11/16 14:24, Andrii Anisov wrote:
Hello Julien,
Please see my comments below:
From my understanding of what you say, the problem is not because domU is using
memory above 4GB but the fact that >the backend driver does not take the right
decision
Yep, the problem could be treated in
Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
which is now fired in a one-shot manner when enabled via the new
VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
The patch also fixes the behaviour of the xc_hvm_inject_trap()
hypercall, which would lead to non-architectural in
Hi Stefano,
On 10/11/16 20:42, Stefano Stabellini wrote:
On Thu, 10 Nov 2016, Julien Grall wrote:
On 10/11/16 00:21, Stefano Stabellini wrote:
On Fri, 4 Nov 2016, Andre Przywara wrote:
On 24/10/16 16:32, Vijay Kilari wrote:
On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara
AFAIK, the
On 11/11/2016 05:48 PM, Razvan Cojocaru wrote:
> Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
> which is now fired in a one-shot manner when enabled via the new
> VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
> The patch also fixes the behaviour of the xc_hvm_inject_tra
On 10/11/16 16:06, Jan Beulich wrote:
> So far we didn't guarantee 16-byte alignment of the stack: While (so
> far) we don't tell the compiler to use smaller alignment, we also don't
> guarantee 16-byte alignment when establishing stack pointers for new
> vCPU-s. Runtime service functions using SSE
On 11/11/2016 05:33 PM, Jan Beulich wrote:
On 11.11.16 at 16:16, wrote:
>> On 11/11/2016 01:09 PM, Jan Beulich wrote:
>> On 11.11.16 at 11:32, wrote:
On 11/11/2016 12:26 PM, Jan Beulich wrote:
On 11.11.16 at 11:15, wrote:
>>> On 11/11/2016 12:02 PM, Jan Beulich wrote:
On 10/11/16 12:29, Jan Beulich wrote:
> When introducing support for these instructions, adjustment for the
> alignment check logic (generating #GP(0)) was overlooked.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing lis
>>> On 11.11.16 at 16:16, wrote:
> On 11/11/2016 01:09 PM, Jan Beulich wrote:
> On 11.11.16 at 11:32, wrote:
>>> On 11/11/2016 12:26 PM, Jan Beulich wrote:
>>> On 11.11.16 at 11:15, wrote:
>> On 11/11/2016 12:02 PM, Jan Beulich wrote:
>> On 11.11.16 at 09:06, wrote:
On 11/11/16 15:32, Jan Beulich wrote:
On 11.11.16 at 16:16, wrote:
>> On Thu, Nov 10, 2016 at 09:50:24AM -0500, Boris Ostrovsky wrote:
>>> Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
>>> APIC ID) with contents of that field on the processor that launched
>>> the gues
>>> On 11.11.16 at 16:16, wrote:
> On Thu, Nov 10, 2016 at 09:50:24AM -0500, Boris Ostrovsky wrote:
>> Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
>> APIC ID) with contents of that field on the processor that launched
>> the guest. This results in the guest reporting diff
On Thu, Nov 10, 2016 at 09:50:24AM -0500, Boris Ostrovsky wrote:
> Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
> APIC ID) with contents of that field on the processor that launched
> the guest. This results in the guest reporting different initial
> APIC IDs across runs.
>
On 11/11/2016 01:09 PM, Jan Beulich wrote:
On 11.11.16 at 11:32, wrote:
>> On 11/11/2016 12:26 PM, Jan Beulich wrote:
>> On 11.11.16 at 11:15, wrote:
> On 11/11/2016 12:02 PM, Jan Beulich wrote:
> On 11.11.16 at 09:06, wrote:
> --- a/xen/include/asm-x86/domain.h
On Fri, Nov 11, 2016 at 1:06 AM, Razvan Cojocaru
wrote:
> Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
> which is now fired in a one-shot manner when enabled via the new
> VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
> The patch also fixes the behaviour of the xc_hvm
On 11/11/16 14:58, Jan Beulich wrote:
On 11.11.16 at 15:16, wrote:
>> On 10/11/16 12:30, Jan Beulich wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -2755,6 +2755,24 @@ static int priv_op_write_msr(unsigned in
>>> return X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>>
>>> On 11.11.16 at 15:16, wrote:
> On 10/11/16 12:30, Jan Beulich wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -2755,6 +2755,24 @@ static int priv_op_write_msr(unsigned in
>> return X86EMUL_UNHANDLEABLE;
>> }
>>
>> +int pv_emul_cpuid(unsigned int *eax, unsigned
Sorry for a confusion.
The sentence:
> Also it does answer to the next question:
should be typed as:
> Also it does NOT answer to the next question:
> > The guest should be IPA agnostic and not care how the physical device is
> > working when using PV drivers. So for me,
> > this should be fixed
Hello Julien,
Please see my comments below:
> From my understanding of what you say, the problem is not because domU is
> using memory above 4GB but the fact that >the backend driver does not take
> the right decision
Yep, the problem could be treated in such a way.
> (e.g using bounce buffer
On 10/11/16 12:30, Jan Beulich wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2755,6 +2755,24 @@ static int priv_op_write_msr(unsigned in
> return X86EMUL_UNHANDLEABLE;
> }
>
> +int pv_emul_cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> +
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 November 2016 12:30
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Wei Liu ; Tim (Xen.org)
>
> Subject: [PATCH] x86: always supply .cpuid() handler to x86_emulate()
>
> With us incremementally adding p
On Thu, Nov 10, 2016 at 05:30:25AM -0700, Jan Beulich wrote:
> With us incremementally adding proper CPUID checks to x86_emulate()
> (see commit de05bd965a ["x86emul: correct {,F}CMOV and F{,U}COMI{,P}
> emulation"]) it is no longer appropriate to invoke the function with
> that hook being NULL, as
On 11/11/16 14:02, Andrew Cooper wrote:
> On 11/11/16 08:00, Juergen Gross wrote:
>> Move functions used in only one source to the file where they are used
>> and make them static.
>>
>> Remove some prototypes from headers which are no longer in use.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> t
On 11/11/16 08:00, Juergen Gross wrote:
> Move functions used in only one source to the file where they are used
> and make them static.
>
> Remove some prototypes from headers which are no longer in use.
>
> Signed-off-by: Juergen Gross
> ---
> tools/xenstore/include/xenstore_lib.h | 15 -
>
Ronald,
I am not sure whether you checked the Outreachy page and apologies for getting
back late, but this project has been accepted. Let me know of your own blog and
whether you'd be willing to write a guest blog or let me cover a quick blog on
blog.xenproject.org as an introduction to the comm
Hello,
On 11/11/16 11:35, Andrii Anisov wrote:
Sorry for the late intrusion into this discussion. I would introduce my
vision of the issues behind the 32 bits addressing DMA controllers in
ARMv7/v8 SoCs.
On AArch64 SoCs, some IPs may only have the capability to access
32 bits address sp
flight 102108 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102108/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 6 xen-boot fail REGR. vs. 102082
Regressions which are r
flight 102100 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102100/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 3 host-install(3) broken REGR. vs. 101909
test-amd64-amd64-
Sorry for the late intrusion into this discussion. I would introduce my
vision of the issues behind the 32 bits addressing DMA controllers in
ARMv7/v8 SoCs.
On AArch64 SoCs, some IPs may only have the capability to access
> 32 bits address space. The physical memory assigned for Dom0 maybe
> not i
Cedric Bosdonnat writes ("Re: [Xen-devel] per-domain logging"):
> I now have a big lot of changes to use the LOG*D family through the
> libxl code. What should be the best way to submit that for review?
> I guess a giant commit won't be too easy to handle for review and
> maintenance, maybe I shou
On 11/11/16 12:12, Jan Beulich wrote:
On 11.11.16 at 11:43, wrote:
>> On 11/11/16 11:09, Jan Beulich wrote:
>> On 11.11.16 at 09:00, wrote:
--- a/xen/include/public/io/xs_wire.h
+++ b/xen/include/public/io/xs_wire.h
@@ -50,6 +50,9 @@ enum xsd_sockmsg_type
XS_SET_
>>> On 11.11.16 at 11:43, wrote:
> On 11/11/16 11:09, Jan Beulich wrote:
> On 11.11.16 at 09:00, wrote:
>>> --- a/xen/include/public/io/xs_wire.h
>>> +++ b/xen/include/public/io/xs_wire.h
>>> @@ -50,6 +50,9 @@ enum xsd_sockmsg_type
>>> XS_SET_TARGET,
>>> XS_RESTRICT,
>>> XS_RES
>>> On 11.11.16 at 11:32, wrote:
> On 11/11/2016 12:26 PM, Jan Beulich wrote:
> On 11.11.16 at 11:15, wrote:
>>> > On 11/11/2016 12:02 PM, Jan Beulich wrote:
>>> > On 11.11.16 at 09:06, wrote:
> >>> --- a/xen/include/asm-x86/domain.h
> >>> +++ b/xen/include/asm-x86/domain.h
>
On 11/11/16 09:00, Juergen Gross wrote:
> Check for failures when allocating new memory in xenstored.
>
> Unfortunately there are several conditions which might render those
> checks void: It might be impossible to send an "ENOMEM" response as
> this requires allocating some memory.
Uuh, sorry. T
On 11/11/16 11:09, Jan Beulich wrote:
On 11.11.16 at 09:00, wrote:
>> --- a/xen/include/public/io/xs_wire.h
>> +++ b/xen/include/public/io/xs_wire.h
>> @@ -50,6 +50,9 @@ enum xsd_sockmsg_type
>> XS_SET_TARGET,
>> XS_RESTRICT,
>> XS_RESET_WATCHES,
>> +XS_DIRECTORY_PART,
>> +
On 11/11/2016 12:26 PM, Jan Beulich wrote:
On 11.11.16 at 11:15, wrote:
>> > On 11/11/2016 12:02 PM, Jan Beulich wrote:
>> > On 11.11.16 at 09:06, wrote:
>>> --- a/xen/include/asm-x86/domain.h
>>> +++ b/xen/include/asm-x86/domain.h
>>> @@ -576,6 +576,10 @@ struct arch_
>>> On 11.11.16 at 11:15, wrote:
> On 11/11/2016 12:02 PM, Jan Beulich wrote:
> On 11.11.16 at 09:06, wrote:
>>> --- a/xen/include/asm-x86/domain.h
>>> +++ b/xen/include/asm-x86/domain.h
>>> @@ -576,6 +576,10 @@ struct arch_vcpu
>>> XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
>>>
On 11/11/2016 12:02 PM, Jan Beulich wrote:
On 11.11.16 at 09:06, wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -2220,6 +2220,20 @@ static void svm_invlpg(struct vcpu *v, unsigned long
>> vaddr)
>> svm_asid_g_invlpg(v, vaddr);
>> }
>>
>> +static
>>> On 11.11.16 at 09:00, wrote:
> --- a/xen/include/public/io/xs_wire.h
> +++ b/xen/include/public/io/xs_wire.h
> @@ -50,6 +50,9 @@ enum xsd_sockmsg_type
> XS_SET_TARGET,
> XS_RESTRICT,
> XS_RESET_WATCHES,
> +XS_DIRECTORY_PART,
> +
> +XS_NEXT_ENTRY, /* First unused typ
>>> On 10.11.16 at 18:21, wrote:
> On Thu, Nov 10, 2016 at 04:20:34PM +0100, Roger Pau Monné wrote:
>> > 0a:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function
>> > (rev 01)
>> > Subsystem: Super Micro Computer Inc Device 10c9
>> > Flags: bus master, fast devsel, lat
>>> On 11.11.16 at 09:06, wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2220,6 +2220,20 @@ static void svm_invlpg(struct vcpu *v, unsigned long
> vaddr)
> svm_asid_g_invlpg(v, vaddr);
> }
>
> +static bool svm_get_pending_event(struct vcpu *v, struct hv
Hi Stefano,
On 11/11/2016 02:24, Stefano Stabellini wrote:
On Thu, 10 Nov 2016, Julien Grall wrote:
(CC Stefano and change the title)
Hello,
On 10/11/16 12:13, casionwoo wrote:
I’m pleased about your reply and you have a lot of code to clean-up.
As you mentioned, It’s really huge to digest
VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
This allows more than 256 VMs to be supported by Xen.
This change adds support for 16-bit VMIDs in Xen based on whether the
architecture supports it.
Signed-off-by: Bhupinder Thakur
---
xen/arch/arm/p2m.c | 44 ++
flight 102104 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102104/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs.
102087
version targeted fo
Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
which is now fired in a one-shot manner when enabled via the new
VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
The patch also fixes the behaviour of the xc_hvm_inject_trap()
hypercall, which would lead to non-architectural in
Reading the children list of a xenstore node with the length of that
list exceeding 4096 bytes is currently not possible. This can be a
problem for a large host with a huge number of domains as Xen tools
will no longer by capable to scan some directories of xenstore (e.g.
/local/domain).
This patc
The layout of the tdb record of xenstored is defined at multiple
places: read_node(), write_node() and in xs_tdb_dump.c
Use a common structure instead.
Signed-off-by: Juergen Gross
---
tools/xenstore/include/xenstore_lib.h | 8
tools/xenstore/xenstored_core.c | 27 ++
The xenstore wire command argument parsing of the different commands
is repeating some patterns multiple times. Add some helper functions
to avoid the duplicated code.
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c | 66 ++--
tools/xenstore/xenstored_d
Instead of always allocating a data buffer for incoming or outgoing
xenstore wire data add a small buffer to the buffered_data structure
of xenstored. This has the advantage that especially sending simple
response messages like errors or "OK" will no longer need allocating
a data buffer. This requi
Move functions used in only one source to the file where they are used
and make them static.
Remove some prototypes from headers which are no longer in use.
Signed-off-by: Juergen Gross
---
tools/xenstore/include/xenstore_lib.h | 15 -
tools/xenstore/xenstore_client.c | 117 ++
In order to prepare adding a generation count to each node modify
add_change_node() to take the connection pointer and a node pointer
instead of the transaction pointer and node name as parameters. This
requires moving the call of add_change_node() from do_rm() to
delete_node_single().
While at it
Add a return value to all wire command functions of xenstored. If such
a function returns an error send the error message in
process_message().
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c| 213 +++--
tools/xenstore/xenstored_domain.c
Check for failures when allocating new memory in xenstored.
Unfortunately there are several conditions which might render those
checks void: It might be impossible to send an "ENOMEM" response as
this requires allocating some memory.
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_cor
In order to be able to support reading the list of a node's children in
multiple chunks (needed for list sizes > 4096 bytes) without having to
allocate a temporary buffer we need some kind of generation counter for
each node. This will help to recognize a node has changed between
reading two chunks
Instead of switch() statements for selecting wire command actions use
an array for this purpose.
While doing this add the XS_RESTRICT type for diagnostic prints and
correct the printed string for XS_IS_DOMAIN_INTRODUCED.
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c | 158 +++
This will enable all users of libxenstore to handle xenstore nodes
with a huge amount of children.
In order to not depend completely on the XS_DIRECTORY_PART
functionality use it only in case of E2BIG returned by XS_DIRECTORY.
Signed-off-by: Juergen Gross
---
tools/xenstore/xs.c | 80 ++
As the payload size for one xenstore wire command is limited to 4096
bytes it is impossible to read the children names of a node with a
large number of children (e.g. /local/domain in case of a host with
more than about 2000 domains). This effectively limits the maximum
number of domains a host can
Instead of calling add_change_node() at places where write_node() is
called, do that inside write_node().
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/x
90 matches
Mail list logo
