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
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
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
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 +++
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 ++
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
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 ++
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
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
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 ++
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
>>> 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
>>> 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: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 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 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: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 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/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 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 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 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_
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
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
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-
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
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
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
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 -
>
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 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
> -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 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,
> +
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
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
>>> 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
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 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/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 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.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 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 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 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/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 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: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
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
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
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
>>> 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
>>> 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 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 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:
> 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 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 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
>
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: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
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 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
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:
> 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
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 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: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: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: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 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 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 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 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
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 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
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
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
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
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
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 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: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
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
90 matches
Mail list logo
