Hi, all!
While working on display protocol I found that there is no(?) common
???_PAGE_SIZE define I can use for both Xen and Linux kernel:
Xen defines XC_PAGE_SIZE which is also used in Linux user-space and
kernel has XEN_PAGE_SIZE, but no XC_PAGE_SIZE.
So, the question is which define shoul
>>> On 01.12.16 at 17:43, wrote:
> On 12/01/2016 11:06 AM, Jan Beulich wrote:
>>
>>> +++ b/xen/include/public/domctl.h
>>> @@ -1144,6 +1144,29 @@ struct xen_domctl_psr_cat_op {
>>> typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
>>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
>>> On 02.12.16 at 04:48, wrote:
> On 12/01/2016 06:58 PM, Jan Beulich wrote:
> On 01.12.16 at 12:04, wrote:
>>> Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
>>> The current MAX_IO_APICS is 128, which causes the driver initialization
>>> to fail on the system wi
This run is configured for baseline tests only.
flight 68147 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68147/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf eae631bc687c3cbfab01632ce3bc21783d22b590
baseline v
On Tue, Nov 29, 2016 at 01:49:51PM +, Julien Grall wrote:
>(CC Stefano)
>
>On 25/11/16 12:19, Iurii Mykhalskyi wrote:
>>Hello!
>
>Hi Iurii,
>
>>
>>I'm working under Renesas Gen3 H3 board with 4GB RAM (Salvator-X)
>>support in Xen mainline.
>>
>>Salvator-X has several CMA pool nodes, for exampl
>>> On 01.12.16 at 18:58, wrote:
> While testing XSA-201, I noticed that Xen 4.5 and 4.5 were not able to
> boot on the Foundation Model [1].
>
> The Foundation Model is a free model provided by ARM for ARMv8 which is
> supported by Xen since the beginning.
>
> I am able to Xen boot after appl
Instead of requesting a new slot on the ring to the backend early, do
so only after all has been setup for the request to be sent. This
makes error handling easier as we don't need to undo the request id
allocation and ring slot allocation.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Instead of requesting a new slot on the ring to the backend early, do
so only after all has been setup for the request to be sent. This
makes error handling easier as we don't need to undo the request id
allocation and ring slot allocation.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Instead of requesting a new slot on the ring to the backend early, do
so only after all has been setup for the request to be sent. This
makes error handling easier as we don't need to undo the request id
allocation and ring slot allocation.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
This run is configured for baseline tests only.
flight 68145 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68145/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 9 debian-di-insta
flight 102755 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102755/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs.
101737
test-amd64-i386-
Hi Jan,
On 12/01/2016 06:58 PM, Jan Beulich wrote:
On 01.12.16 at 12:04, wrote:
Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
The current MAX_IO_APICS is 128, which causes the driver initialization
to fail on the system with IOAPIC ID >= 128.
Instead, this patch
Hi,
Thanks a lot. I find that if guest writes or reads MSR related to
MTRR which will cause vm exit, xen will just calculate mtrr type and store
it without setting the EPT. Why doesn't xen set the memory type (ie,emt
filed)in entry of EPT when handling vm exit resulting from writing/reading
MSR re
flight 102754 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102754/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101675
test-amd64-i386-libv
On Wed, 30 Nov 2016, David Vrabel wrote:
> On 29/11/16 23:34, Stefano Stabellini wrote:
> >
> > The producer (the backend for **in**, the frontend for **out**) writes to
> > the
> > array in the following way:
> >
> - read memory barrier
> > - read *cons*, *prod* from shared memory
> > - write t
flight 102751 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102751/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 3 host-install(3)broken REGR. vs. 102521
build-armhf
On Thu, 1 Dec 2016, Dario Faggioli wrote:
> On Tue, 2016-11-29 at 15:34 -0800, Stefano Stabellini wrote:
> > ### Frontend XenBus Nodes
> >
> > num-rings
> > Values:
> >
> > Number of rings. It needs to be lower or equal to max-rings.
> >
> > port- (port
On Thu, 1 Dec 2016, Lars Kurth wrote:
> On 01/12/2016 22:36, "Stefano Stabellini" wrote:
>
> >On Thu, 1 Dec 2016, Ian Jackson wrote:
> >> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision
> >>making; some new roles and minor changes"):
> >> > Maybe Ian has some views on what
On 01/12/2016 22:36, "Stefano Stabellini" wrote:
>On Thu, 1 Dec 2016, Ian Jackson wrote:
>> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision
>>making; some new roles and minor changes"):
>> > Maybe Ian has some views on what is better from a theoretical
>>viewpoint:
>> > V
On Thu, 1 Dec 2016, Ian Jackson wrote:
> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision
> making; some new roles and minor changes"):
> > Maybe Ian has some views on what is better from a theoretical viewpoint:
> > Voting mechanisms are a bit of a hobby of his
>
> The unde
Done
On Thu, 1 Dec 2016, Julien Grall wrote:
> Hi,
>
> While testing XSA-201, I noticed that Xen 4.5 and 4.5 were not able to boot on
> the Foundation Model [1].
>
> The Foundation Model is a free model provided by ARM for ARMv8 which is
> supported by Xen since the beginning.
>
> I am able to
On Thu, 1 Dec 2016, Christoffer Dall wrote:
> On Wed, Nov 30, 2016 at 02:26:50PM -0800, Stefano Stabellini wrote:
> > On Wed, 30 Nov 2016, Julien Grall wrote:
> > > Hi all,
> > >
> > > Few months ago, Linaro has published the version 2 of the VM specification
> > > [1].
> > >
> > > For those who
On Thu, 1 Dec 2016, Julien Grall wrote:
> On 01/12/16 02:07, Stefano Stabellini wrote:
> > On Fri, 25 Nov 2016, Julien Grall wrote:
> > > Hi Stefano,
>
> Hi,
>
> > > On 23/11/16 19:55, Stefano Stabellini wrote:
> > > > Actually I am thinking that the default values should be in the
> > > > emulat
flight 102750 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102750/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102726
test-armhf-armhf-libvirt 13
On Thu, 1 Dec 2016, Volodymyr Babchuk wrote:
> > - TEE may run in parallel of the guest OS, this means that we have
> > to make sure the page will never be removed by the guest OS (see
> > XENMEM_decrease_reservation hypercall).
> Hmmm... I don't know how XEN handles guest memory in details
On Thu, 1 Dec 2016, Volodymyr Babchuk wrote:
> Hello Julien,
>
>
>
> On 1 December 2016 at 16:24, Julien Grall wrote:
> > Hi Stefano,
> >
> >
> > On 30/11/16 21:53, Stefano Stabellini wrote:
> >>
> >> On Mon, 28 Nov 2016, Julien Grall wrote:
> >
> > If not, then it might be worth to con
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 102749 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102749/
Perfect :-)
All tests
On Wed, Nov 30, 2016 at 12:30:04PM +1100, George Dunlap wrote:
> On Tue, Nov 29, 2016 at 4:18 AM, Ronald Rojas wrote:
> > Created basic Makfele for the Golang xenlight
> > project so that the project is built and
> > installed. A template template is alo added.
>
> Thanks Ronald! Not a bad first
On 12/01/2016 11:55 AM, Andrew Cooper wrote:
> The common case is already using fault semantics out of x86_emulate(), as that
> is how VT-x/SVM expects to inject the event (given suitable hardware support).
>
> However, x86_emulate() returning X86EMUL_EXCEPTION and also completing a
> register writ
On Wed, Nov 30, 2016 at 07:21:48AM +0100, Ingo Molnar wrote:
>
> * Alex Thorlton wrote:
>
> > It's really not necessary to limit E820_X_MAX to 128 in the non-EFI
> > case. This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that
> > E820_X_MAX is always at least slightly larger than E82
flight 102744 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102744/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-raw 10 guest-start fail in 102725 pass in 102744
test-armhf-armhf-xl-vhd
flight 102745 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102745/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf eae631bc687c3cbfab01632ce3bc21783d22b590
baseline version:
ovmf e148e6e9625f8a0054f13
Hi,
While testing XSA-201, I noticed that Xen 4.5 and 4.5 were not able to
boot on the Foundation Model [1].
The Foundation Model is a free model provided by ARM for ARMv8 which is
supported by Xen since the beginning.
I am able to Xen boot after applying the patch:
eb6fe7a "arm64: fix inc
On 28/11/16 15:29, t...@kernel.org wrote:
Hello,
Hello,
On Mon, Nov 28, 2016 at 11:59:15AM +, Julien Grall wrote:
commit 3ca45a46f8af8c4a92dd8a08eac57787242d5021
percpu: ensure the requested alignment is power of two
It would have been useful to specify the tree used. In this case,
t
Hi.
Xen 4.8.0 RC8 is tagged. You can check it out from xen.git, where
there is a signed tag:
git://xenbits.xen.org/xen.git 4.8.0-rc8
For you convenience, please find tarball and signature at:
https://downloads.xenproject.org/release/xen/4.8.0-rc8/
Please send bug reports and test reports
On 12/01/2016 11:32 AM, Jan Beulich wrote:
On 29.11.16 at 16:33, wrote:
>> +void hvm_acpi_init(struct domain *d)
>> +{
>> +if ( has_acpi_dm_ff(d) )
>> +return;
>> +
>> +register_portio_handler(d, XEN_ACPI_CPU_MAP,
>> +XEN_ACPI_CPU_MAP_LEN, acpi_gues
Use x86_emul_{hw_exception,pagefault}() rather than
{pv,hvm}_inject_page_fault() and hvm_inject_hw_exception() to cause raised
faults to be known to the emulator. This requires altering the callers of
x86_emulate() to properly re-inject the event.
Signed-off-by: Andrew Cooper
Acked-by: Tim Deega
Use x86_emul_pagefault() rather than pv_inject_page_fault() to cause raised
pagefaults to be known to the emulator. This requires altering the callers of
x86_emulate() to properly re-inject the event.
Signed-off-by: Andrew Cooper
Acked-by: Tim Deegan
Reviewed-by: Jan Beulich
---
v4:
* Tweak c
The behaviour of singlestep is to raise #DB after the instruction has been
completed, but implementing it with inject_hw_exception() causes x86_emulate()
to return X86EMUL_EXCEPTION, despite succesfully completing execution of the
instruction, including register writeback.
Instead, use a retire fl
The common case is already using fault semantics out of x86_emulate(), as that
is how VT-x/SVM expects to inject the event (given suitable hardware support).
However, x86_emulate() returning X86EMUL_EXCEPTION and also completing a
register writeback is problematic for callers.
Switch the logic to
This is the quantity of changes required to fix some edgecases in XSA-191
which were ultimately chosen not to go out in the security fix. The main
purpose of this series is to fix emulation sufficiently to allow the final
patch to avoid opencoding all of the segmenation logic.
Because this is a v
In debug builds, confirm that some properties of x86_emulate()'s behaviour
actually hold. The first property, fixed in a previous change, is that retire
flags are only ever set in the X86EMUL_OKAY case.
While adjusting the userspace test harness to cope with ASSERT() in
x86_emulate.h, fix a build
On 12/01/2016 11:29 AM, Andrew Cooper wrote:
> On 01/12/16 16:28, Boris Ostrovsky wrote:
>> On 12/01/2016 10:52 AM, Jan Beulich wrote:
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -525,16 +525,16 @@ DECLARE_HVM_SAVE_TYPE(HPET, 12, struc
On 12/01/2016 11:06 AM, Jan Beulich wrote:
>
>> +++ b/xen/include/public/domctl.h
>> @@ -1144,6 +1144,29 @@ struct xen_domctl_psr_cat_op {
>> typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
>>
>> +/* ACPI Generic Address Structu
>>> On 29.11.16 at 16:33, wrote:
> +void hvm_acpi_init(struct domain *d)
> +{
> +if ( has_acpi_dm_ff(d) )
> +return;
> +
> +register_portio_handler(d, XEN_ACPI_CPU_MAP,
> +XEN_ACPI_CPU_MAP_LEN, acpi_guest_access);
> +register_portio_handler(d, ACPI_G
On 01/12/16 16:28, Boris Ostrovsky wrote:
> On 12/01/2016 10:52 AM, Jan Beulich wrote:
>>> --- a/xen/include/public/arch-x86/hvm/save.h
>>> +++ b/xen/include/public/arch-x86/hvm/save.h
>>> @@ -525,16 +525,16 @@ DECLARE_HVM_SAVE_TYPE(HPET, 12, struct hvm_hw_hpet);
>>>
>>>
>>> /*
>>> - * PM time
Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision making;
some new roles and minor changes"):
> Maybe Ian has some views on what is better from a theoretical viewpoint:
> Voting mechanisms are a bit of a hobby of his
The underlying problem here is that the reality is that the
On 12/01/2016 10:57 AM, Jan Beulich wrote:
On 29.11.16 at 16:33, wrote:
>> --- a/xen/include/public/arch-x86/xen.h
>> +++ b/xen/include/public/arch-x86/xen.h
>> @@ -291,6 +291,13 @@ struct xen_arch_domainconfig {
>> XEN_X86_EMU_PIT)
>> uint32_t emula
On 12/01/2016 10:52 AM, Jan Beulich wrote:
>> --- a/xen/include/public/arch-x86/hvm/save.h
>> +++ b/xen/include/public/arch-x86/hvm/save.h
>> @@ -525,16 +525,16 @@ DECLARE_HVM_SAVE_TYPE(HPET, 12, struct hvm_hw_hpet);
>>
>>
>> /*
>> - * PM timer
>> + * ACPI registers
>> */
>>
>> -struct hvm
flight 102741 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102741/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-freebsd10-amd64 10 guest-start fail in 102723 pass in 102741
test-amd64-i386-xl-raw
On Thu, Dec 01, 2016 at 09:08:45AM -0700, Jan Beulich wrote:
> >>> On 01.12.16 at 16:41, wrote:
> > On Thu, Dec 01, 2016 at 06:13:34AM -0700, Jan Beulich wrote:
> >> >>> On 30.11.16 at 14:04, wrote:
> >> > --- a/xen/common/efi/boot.c
> >> > +++ b/xen/common/efi/boot.c
> >> > @@ -98,6 +98,52 @@ st
>>> On 01.12.16 at 16:41, wrote:
> On Thu, Dec 01, 2016 at 06:13:34AM -0700, Jan Beulich wrote:
>> >>> On 30.11.16 at 14:04, wrote:
>> > --- a/xen/common/efi/boot.c
>> > +++ b/xen/common/efi/boot.c
>> > @@ -98,6 +98,52 @@ static CHAR16 __initdata newline[] = L"\r\n";
>> > #define PrintStr(s) Std
>>> On 29.11.16 at 16:33, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/hvm/acpi.c
> @@ -0,0 +1,24 @@
> +/* acpi.c: ACPI access handling
> + *
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> + */
> +#include
> +#include
> +#include
> +
> +
> +int hvm_acpi_domctl_acce
>>> On 29.11.16 at 16:33, wrote:
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -291,6 +291,13 @@ struct xen_arch_domainconfig {
> XEN_X86_EMU_PIT)
> uint32_t emulation_flags;
> };
> +
> +/* Location of online VC
>>> On 29.11.16 at 16:33, wrote:
> @@ -108,12 +111,12 @@ static void pmt_update_time(PMTState *s)
> s->last_gtime = curr_gtime;
>
> /* Update timer value atomically wrt lock-free reads in handle_pmt_io().
> */
> -*(volatile uint32_t *)&s->pm.tmr_val = tmr_val;
> +*(volatile ui
Hi Christoffer,
On 30/11/16 16:24, Christoffer Dall wrote:
On Wed, Nov 30, 2016 at 03:29:32PM +, Julien Grall wrote:
Hi all,
Few months ago, Linaro has published the version 2 of the VM
specification [1].
For those who don't know, the specification provides guidelines to
guarantee a compl
On Thu, Dec 01, 2016 at 06:13:34AM -0700, Jan Beulich wrote:
> >>> On 30.11.16 at 14:04, wrote:
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -98,6 +98,52 @@ static CHAR16 __initdata newline[] = L"\r\n";
> > #define PrintStr(s) StdOut->OutputString(StdOut, s)
> > #define
On 01/12/16 02:07, Stefano Stabellini wrote:
On Fri, 25 Nov 2016, Julien Grall wrote:
Hi Stefano,
Hi,
On 23/11/16 19:55, Stefano Stabellini wrote:
Actually I am thinking that the default values should be in the
emulators themselves. After all they are the part of the code that knows
more ab
Hi Julien
On 1 December 2016 at 17:19, Julien Grall wrote:
> On 29/11/16 19:19, Volodymyr Babchuk wrote:
>>
>> Hi Julien,
>
>
> Hi Volodymyr,
>
>
>>
>>
>> On 29 November 2016 at 20:55, Julien Grall wrote:
>>>
>>> Hi Volodymyr,
>>>
>>> On 29/11/16 17:40, Volodymyr Babchuk wrote:
On
On 10/31/2016 08:33 AM, Boris Ostrovsky wrote:
>
>
> On 10/14/2016 02:05 PM, Boris Ostrovsky wrote:
>> From: Matt Fleming
>>
>> The new Xen PVH entry point requires page tables to be setup by the
>> kernel since it is entered with paging disabled.
>>
>> Pull the common code out of head_32.S and in
>>> On 01.12.16 at 16:08, wrote:
> On Thu, Dec 01, 2016 at 12:40:01PM +, Roger Pau Monne wrote:
>> --- a/tools/libacpi/acpi2_0.h
>> +++ b/tools/libacpi/acpi2_0.h
>> @@ -229,6 +229,7 @@ struct acpi_20_fadt {
>> */
>> #define ACPI_LEGACY_DEVICES (1 << 0)
>> #define ACPI_8042 (1 <<
On 29/11/16 19:19, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
On 29 November 2016 at 20:55, Julien Grall wrote:
Hi Volodymyr,
On 29/11/16 17:40, Volodymyr Babchuk wrote:
On 29 November 2016 at 18:02, Julien Grall wrote:
On 29/11/16 15:27, Volodymyr Babchuk wrote:
On 28 Nove
On Thu, Dec 01, 2016 at 12:40:01PM +, Roger Pau Monne wrote:
> --- a/tools/libacpi/acpi2_0.h
> +++ b/tools/libacpi/acpi2_0.h
> @@ -229,6 +229,7 @@ struct acpi_20_fadt {
> */
> #define ACPI_LEGACY_DEVICES (1 << 0)
> #define ACPI_8042 (1 << 1)
> +#define ACPI_FADT_NO_VGA(1 << 2)
Hello Julien,
On 1 December 2016 at 16:24, Julien Grall wrote:
> Hi Stefano,
>
>
> On 30/11/16 21:53, Stefano Stabellini wrote:
>>
>> On Mon, 28 Nov 2016, Julien Grall wrote:
>
> If not, then it might be worth to consider a 3rd solution where the TEE
> SMC
> calls are forwarded
Thursday, December 1, 2016, 2:59:36 PM, you wrote:
> On 01.12.2016 14:26, Wei Liu wrote:
>> This is still the same kernel log that was sent some time ago.
>> So, if you have built Xen with debug=y, could you try to set Xen log
>> level to the highest and capture "xl dmesg" when guest crashes?
>
On Fri, Nov 18, 2016 at 03:59:59PM +, Wei Liu wrote:
> On Thu, Nov 17, 2016 at 06:35:42PM +0100, Cédric Bosdonnat wrote:
> > Hey all,
> >
> > Here is v2 addressing Wei's comments on patch #1. The 3 libxl.c
> > patches haven't been merged, but the commit message of the first
> > one has been sl
Hi Stefano,
On 30/11/16 21:53, Stefano Stabellini wrote:
On Mon, 28 Nov 2016, Julien Grall wrote:
If not, then it might be worth to consider a 3rd solution where the TEE
SMC
calls are forwarded to a specific domain handling the SMC on behalf of the
guests. This would allow to upgrade the TEE la
This run is configured for baseline tests only.
flight 68131 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68131/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-insta
On Thu, Dec 01, 2016 at 02:59:36PM +0100, Ingo Jürgensmann wrote:
> On 01.12.2016 14:26, Wei Liu wrote:
>
> >This is still the same kernel log that was sent some time ago.
> >So, if you have built Xen with debug=y, could you try to set Xen log
> >level to the highest and capture "xl dmesg" when gu
flight 102735 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102735/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102704
test-armhf-armhf-libvirt-qc
On 01.12.2016 14:26, Wei Liu wrote:
This is still the same kernel log that was sent some time ago.
So, if you have built Xen with debug=y, could you try to set Xen log
level to the highest and capture "xl dmesg" when guest crashes?
It's not the guest that crashes, it's dom0. So when the host c
On 12/01/2016 08:29 AM, Roger Pau Monne wrote:
On Thu, Dec 01, 2016 at 06:09:09AM -0700, Jan Beulich wrote:
On 01.12.16 at 13:40, wrote:
PVHv2 guests don't have any VGA card, and as so it must be notified in the
FADT.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Looking at t
On 30.11.16 21:21, Andrew Cooper wrote:
> On 29/11/16 15:09, Artem Mygaiev wrote:
>> Hi Julien
>>
>> On 29.11.16 16:27, Julien Grall wrote:
>>> Hi Artem,
>>>
>>> On 29/11/16 14:21, Artem Mygaiev wrote:
Lars, the project is approved by Coverity. Scan has found some issues in
xen/arch/arm o
On Tue, Nov 29, 2016 at 11:15:36AM -0800, Stefano Stabellini wrote:
> On Tue, 29 Nov 2016, Juergen Gross wrote:
> > On 29/11/16 08:34, Wei Liu wrote:
> > > On Mon, Nov 28, 2016 at 02:53:57PM +0100, Cédric Bosdonnat wrote:
> > >> Resume is sometimes silently failing for HVM guests. Getting the
> > >
On Thu, Dec 01, 2016 at 06:09:09AM -0700, Jan Beulich wrote:
> >>> On 01.12.16 at 13:40, wrote:
> > PVHv2 guests don't have any VGA card, and as so it must be notified in the
> > FADT.
> >
> > Signed-off-by: Roger Pau Monné
>
> Reviewed-by: Jan Beulich
>
> Looking at this ...
>
> > --- a/to
>>> On 01.12.16 at 14:12, wrote:
> On 01/12/16 12:57, Jan Beulich wrote:
> On 30.11.16 at 14:50, wrote:
>>> @@ -5379,30 +5380,41 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned
>>> long addr,
>>> page_unlock(page);
>>> put_page(page);
>>>
>>> -/*
>>> - * The previous l
On Tue, Nov 29, 2016 at 09:20:55PM +0100, Ingo Jürgensmann wrote:
> Am 29.11.2016 um 10:08 schrieb Wei Liu :
> >> http://paste.debian.net/895464/
> > Entry not found -- maybe it expired... Sorry.
>
> Here it is:
>
This is still the same kernel log that was sent some time ago.
So, if you have b
On Wed, Nov 30, 2016 at 05:47:51PM +0800, Zhang Chen wrote:
> Because of qemu codes update, we update Xen colo block codes
>
> Signed-off-by: Zhang Chen
COLO being an experimental feature means that you can change it at will,
so for both patches:
Acked-by: Wei Liu
But, this sort of patch does
On Wed, Nov 30, 2016 at 05:47:50PM +0800, Zhang Chen wrote:
> The ioreq server make colo run failed.
>
> Signed-off-by: Zhang Chen
> Signed-off-by: Wen Congyang
> ---
> xen/arch/x86/hvm/hvm.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch
On 01/12/16 13:00, Jan Beulich wrote:
On 30.11.16 at 14:50, wrote:
>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -3373,18 +3373,35 @@ static int sh_page_fault(struct vcpu *v,
>>
>> r = x86_emulate(&emul_ctxt.ctxt, emul_ops);
>>
>> -/*
>> -
>>> On 30.11.16 at 14:04, wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -98,6 +98,52 @@ static CHAR16 __initdata newline[] = L"\r\n";
> #define PrintStr(s) StdOut->OutputString(StdOut, s)
> #define PrintErr(s) StdErr->OutputString(StdErr, s)
>
> +#ifndef CONFIG_ARM
>
On 01/12/16 12:57, Jan Beulich wrote:
On 30.11.16 at 14:50, wrote:
>> @@ -5379,30 +5380,41 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long
>> addr,
>> page_unlock(page);
>> put_page(page);
>>
>> -/*
>> - * The previous lack of inject_{sw,hw}*() hooks caused except
>>> On 01.12.16 at 13:40, wrote:
> PVHv2 guests don't have any VGA card, and as so it must be notified in the
> FADT.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Looking at this ...
> --- a/tools/libacpi/acpi2_0.h
> +++ b/tools/libacpi/acpi2_0.h
> @@ -229,6 +229,7 @@ struct
>>> On 30.11.16 at 14:50, wrote:
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -3373,18 +3373,35 @@ static int sh_page_fault(struct vcpu *v,
>
> r = x86_emulate(&emul_ctxt.ctxt, emul_ops);
>
> -/*
> - * The previous lack of inject_{sw,hw}*() ho
>>> On 30.11.16 at 14:50, wrote:
> @@ -5379,30 +5380,41 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long
> addr,
> page_unlock(page);
> put_page(page);
>
> -/*
> - * The previous lack of inject_{sw,hw}*() hooks caused exceptions raised
> - * by the emulator itself t
On 01/12/2016 09:52, "Lars Kurth" wrote:
>On 30/11/2016 23:27, "Stefano Stabellini" wrote:
>
>>On Wed, 23 Nov 2016, Lars Kurth wrote:
>>>
>>>
>>
>>This is basically the same voting mechanism described under "Leadership
>>Team
>>Decisions", counted per project, then averaged, isn't?
>
>That is
PVHv2 guests don't have any VGA card, and as so it must be notified in the FADT.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.com
---
tools/firmware/hvmloader/util.c | 3 ++-
tools/libac
>>> On 30.11.16 at 14:50, wrote:
> The emulator needs to gain an understanding of interrupts and exceptions
> generated by its actions.
>
> Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they
> are visible to the emulator. This removes the need for the
> inject_{hw_exce
>>> On 01.12.16 at 11:29, wrote:
>> (XEN) Enabling APIC mode: Flat. Using 2 I/O APICs
>> (XEN) [VT-D] RMRR address range bf7da000..bf7d9fff not in reserved memory;
>> need "iommu_inclusive_mapping=1"?
>> (XEN) [VT-D] RMRR (bf7da000, bf7d9fff) is incorrect
>> (XEN) Failed to parse ACPI DMAR. D
>>> On 01.12.16 at 12:23, wrote:
> On 01/12/16 11:16, Jan Beulich wrote:
> On 30.11.16 at 14:50, wrote:
>>> @@ -3422,6 +3422,16 @@ static int sh_page_fault(struct vcpu *v,
>>> v->arch.paging.last_write_emul_ok = 0;
>>> #endif
>>>
>>> +if ( emul_ctxt.ctxt.retire.singlestep )
>>
>>> On 01.12.16 at 12:04, wrote:
> Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
> The current MAX_IO_APICS is 128, which causes the driver initialization
> to fail on the system with IOAPIC ID >= 128.
>
> Instead, this patch adds APIC ID in the struct ioapic_sbdf,
>
At 13:50 + on 30 Nov (1480513834), Andrew Cooper wrote:
> Use x86_emul_pagefault() rather than pv_inject_page_fault() to cause raised
> pagefaults to be known to the emulator. This requires altering the callers of
> x86_emulate() to properly re-inject the event.
>
> Signed-off-by: Andrew Coop
On 01/12/16 11:39, Tim Deegan wrote:
> At 13:50 + on 30 Nov (1480513835), Andrew Cooper wrote:
>> Use x86_emul_{hw_exception,pagefault}() rather than
>> {pv,hvm}_inject_page_fault() and hvm_inject_hw_exception() to cause raised
>> faults to be known to the emulator. This requires altering the
At 13:50 + on 30 Nov (1480513835), Andrew Cooper wrote:
> Use x86_emul_{hw_exception,pagefault}() rather than
> {pv,hvm}_inject_page_fault() and hvm_inject_hw_exception() to cause raised
> faults to be known to the emulator. This requires altering the callers of
> x86_emulate() to properly re-
At 13:50 + on 30 Nov (1480513830), Andrew Cooper wrote:
> The emulator needs to gain an understanding of interrupts and exceptions
> generated by its actions.
>
> Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they
> are visible to the emulator. This removes the need
At 11:23 + on 01 Dec (1480591394), Andrew Cooper wrote:
> Hmm. It is only the PAE case we want to skip. Perhaps changing the PAE
> entry condition to
>
> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> index c45d260..28ff945 100644
> --- a/xen/arch/x86/mm/shado
flight 102740 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102740/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 1f021c88130b4d2d818ba4f269b3929339c00a88
baseline version:
xtf 36431397ac902e791e16a0
At 16:49 + on 30 Nov (1480524579), Roger Pau Monne wrote:
> ... and using the "preempted" parameter. Introduce a new helper that can
> be used from both hypercall or idle vcpu context (ie: during Dom0
> creation) in order to check if preemption is needed. If such preemption
> happens, the calle
>>> On 01.12.16 at 12:15, wrote:
> On 01/12/16 10:53, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -1694,8 +1694,6 @@ static int inject_swint(enum x86_swint_type type,
>>> goto raise_exn;
>>>
On 01/12/16 11:16, Jan Beulich wrote:
On 30.11.16 at 14:50, wrote:
>> The behaviour of singlestep is to raise #DB after the instruction has been
>> completed, but implementing it with inject_hw_exception() causes
>> x86_emulate()
>> to return X86EMUL_EXCEPTION, despite succesfully completing
1 - 100 of 119 matches
Mail list logo
