On 09.11.2016 13:14, Julien Grall wrote:
Hello,
On 09/11/16 07:14, Dirk Behme wrote:
On 08.11.2016 16:41, Iurii Mykhalskyi wrote:
Hello Dirk,
I have made only single change - I recompile ATF to leave CPU in EL2
mode and reflash it.
Yes, this is what I meant with 'modifying firmware' ;)
Yo
flight 102068 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102068/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-xsm 3 host-install(3) broken pass in 102045
test-amd64-i386-xl-qemuu-ovmf-am
flight 102067 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102067/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl 6 xen-boot fail in 101695 pass in 102067
test-amd64-amd64-libvirt-vhd 6 xen
On 16-11-09 01:37:55, Jan Beulich wrote:
> >>> On 09.11.16 at 02:28, wrote:
> > Any comment or suggestion to this patch set? That would be very appreciated.
>
> Please be assured that this has not been forgotten, but there are
> more important things to deal with, so it may take some more time
>
From: Arnd Bergmann
Date: Tue, 8 Nov 2016 14:34:34 +0100
> The connect function prints an unintialized error code after an
> earlier initialization was removed:
>
> drivers/net/xen-netback/xenbus.c: In function 'connect':
> drivers/net/xen-netback/xenbus.c:938:3: error: 'err' may be used
> uni
From: "Jan Beulich"
Date: Tue, 08 Nov 2016 00:45:53 -0700
> For single items being collected this should be preferred as being more
> typesafe (as the compiler can check format string and to-be-written-to
> variable match) and more efficient (requiring one less parameter to be
> passed).
>
> Sig
On 11/10/2016 01:31 AM, Sadi wrote:
> Hello again,
>
> Looking at the primary host's syslog, the arptables command from
> xen/etc/scripts/colo-proxy-setup has failed.
>
> Here's the log:
>
> Nov 9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: setup
> XENBUS_PATH=
> Nov 9 14:43:39
flight 102079 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102079/
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 Wed, 28 Sep 2016, Andre Przywara wrote:
> To let a guest know about the availability of virtual LPIs, set the
> respective bits in the virtual GIC registers and let a guest control
> the LPI enable bit.
> Only report the LPI capability if the host has initialized at least
> one ITS.
>
> Signed-
On Wed, 28 Sep 2016, Andre Przywara wrote:
> For each hardware ITS create and initialize a virtual ITS for Dom0.
> We use the same memory mapped address to keep the doorbell working.
>
> Signed-off-by: Andre Przywara
> ---
> xen/arch/arm/vgic-its.c | 22 ++
> xen/arch/a
On Fri, 4 Nov 2016, Andre Przywara wrote:
> Hi,
>
> On 24/10/16 16:32, Vijay Kilari wrote:
> > On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara
> > wrote:
> >> The INVALL command instructs an ITS to invalidate the configuration
> >> data for all LPIs associated with a given redistributor (read:
Hi Julien, all,
> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.
great idea, I'd like to join too (GMT).
> Example of features that could be discussed:
> - Sharing co-processor between guests
> - PCI passthro
On Wed, 9 Nov 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 08/11/16 19:42, Stefano Stabellini wrote:
> > @@ -1189,7 +1194,10 @@ static int __init gicv2_init(void)
> > printk(XENLOG_WARNING
> > "GICv2: Adjusting CPU interface base to %#"PRIx64"\n",
> > cba
flight 102063 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102063/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 6 xen-bootfail REGR. vs. 100648
test-amd64-i386-xl-x
On 11/09/2016 02:58 PM, Andrew Cooper wrote:
> On 09/11/16 15:14, Boris Ostrovsky wrote:
>> On 11/09/2016 09:59 AM, Andrew Cooper wrote:
diff --git a/xen/include/public/hvm/ioreq.h
b/xen/include/public/hvm/ioreq.h
index 2e5809b..e3fa704 100644
--- a/xen/include/public/hvm/ioreq
On Wed, Nov 09, 2016 at 06:51:49PM +, Andrew Cooper wrote:
> >
> > Low 1MB
> > ---
> >
> > When booted with a legacy BIOS, the low 1MB contains firmware related data
> > that should be identity mapped to the Dom0. This include the EBDA, video
> > memory and possibly ROMs. All non RAM region
On 09/11/16 15:14, Boris Ostrovsky wrote:
> On 11/09/2016 09:59 AM, Andrew Cooper wrote:
>>> diff --git a/xen/include/public/hvm/ioreq.h b/xen/include/public/hvm/ioreq.h
>>> index 2e5809b..e3fa704 100644
>>> --- a/xen/include/public/hvm/ioreq.h
>>> +++ b/xen/include/public/hvm/ioreq.h
>>> @@ -24,6
On 11/09/2016 02:23 PM, Andrew Cooper wrote:
> On 09/11/16 15:29, Boris Ostrovsky wrote:
>> On 11/09/2016 10:04 AM, Andrew Cooper wrote:
>>> On 09/11/16 14:39, Boris Ostrovsky wrote:
This domctl is called when a VCPU is hot-(un)plugged to a guest (via
'xl vcpu-set'). While this currently
On 09/11/16 15:29, Boris Ostrovsky wrote:
> On 11/09/2016 10:04 AM, Andrew Cooper wrote:
>> On 09/11/16 14:39, Boris Ostrovsky wrote:
>>> This domctl is called when a VCPU is hot-(un)plugged to a guest (via
>>> 'xl vcpu-set'). While this currently is only intended to be needed by
>>> PVH guests we
On 09/11/16 15:59, Roger Pau Monné wrote:
> Hello,
>
> I'm attaching a draft of how a PVHv2 Dom0 is supposed to interact with
> physical devices, and what needs to be done inside of Xen in order to
> achieve it. Current draft is RFC because I'm quite sure I'm missing bits
> that should be writte
On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote:
> Hello,
>
> I'm attaching a draft of how a PVHv2 Dom0 is supposed to interact with
> physical devices, and what needs to be done inside of Xen in order to
> achieve it. Current draft is RFC because I'm quite sure I'm missing bits
On 09/11/16 14:14, Jan Beulich wrote:
On 09.11.16 at 13:28, wrote:
>> The original code has a bug; eax and edx get unconditionally updated even
>> when
>> hvm_msr_read_intercept() doesn't return X86EMUL_OKAY.
>>
>> It is only by blind luck (vmce_rdmsr() eagerly initialising its msr_content
>
Hello again,
Looking at the primary host's syslog, the arptables command from
xen/etc/scripts/colo-proxy-setup has failed.
Here's the log:
Nov 9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: setup
XENBUS_PATH=
Nov 9 14:43:39 colop kernel: [ 302.825788] u32 classifier
Nov 9 14:43:3
We just discussed this IRL, and here are our conclusions:
Ian Jackson writes ("Re: [OSSTEST PATCH v6 3/3] Create a flight to test
OpenStack with xen-unstable and libvirt"):
> Do we intend to try to gate xen-unstable on this eventually ?
Maybe eventually, but not right now.
> AFAICT you pull in
flight 102065 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102065/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c3c9892c3b4dafd1d0ccdc8e5e017d80e8c4361e
baseline version:
ovmf 008e2ccf02e7be65b3a1b
On Wed, Nov 09, 2016 at 03:13:16PM +0100, Sylvain Munaut wrote:
> Hi,
>
>
> A bit of background: What I'm currently trying to do is to network
> boot a first linux image in EFI mode (using UEFI network boot), then
> from that image, kexec into Xen in EFI mode as well.
>
> It's not working.
>
>
Anthony PERARD writes ("[OSSTEST PATCH v6 3/3] Create a flight to test
OpenStack with xen-unstable and libvirt"):
> This patch should create a flight "openstack-nova", with those jobs:
> build-amd64
> build-amd64-xsm
> build-amd64-pvops
> build-amd64-libvirt
> test-amd64-amd64-devstack
>
Anthony PERARD writes ("[OSSTEST PATCH v6 2/3] ts-openstack-tempest: Run
Tempest to check OpenStack"):
> This script runs the OpenStack integration test suite, Tempest.
...
> + push @ignored_tests,
> + "^\Q$volume_boot_pattern.test_volume_boot_pattern\E";
> + push @ignored_tests,
> + "
Anthony PERARD writes ("[OSSTEST PATCH v6 1/3] ts-openstack-deploy: Deploy
OpenStack on a host with devstack"):
> This script installs any necessary packages and clones all of the OpenStack
> trees which are used by devstack to deploy OpenStack.
Thanks for this contribution. I have no knowledge
On 11/09/2016 07:28 AM, Andrew Cooper wrote:
> The original code has a bug; eax and edx get unconditionally updated even when
> hvm_msr_read_intercept() doesn't return X86EMUL_OKAY.
>
> It is only by blind luck (vmce_rdmsr() eagerly initialising its msr_content
> pointer) that this isn't an informa
Hello,
I'm attaching a draft of how a PVHv2 Dom0 is supposed to interact with
physical devices, and what needs to be done inside of Xen in order to
achieve it. Current draft is RFC because I'm quite sure I'm missing bits
that should be written down here. So far I've tried to describe what my
p
osstest service owner writes ("[linux-3.10 test] 102032: regressions - FAIL"):
> flight 102032 linux-3.10 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/102032/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-
On 11/09/2016 10:04 AM, Andrew Cooper wrote:
> On 09/11/16 14:39, Boris Ostrovsky wrote:
>> This domctl is called when a VCPU is hot-(un)plugged to a guest (via
>> 'xl vcpu-set'). While this currently is only intended to be needed by
>> PVH guests we will call this domctl for all (x86) guests for c
On 11/09/2016 09:59 AM, Andrew Cooper wrote:
>
>> diff --git a/xen/include/public/hvm/ioreq.h b/xen/include/public/hvm/ioreq.h
>> index 2e5809b..e3fa704 100644
>> --- a/xen/include/public/hvm/ioreq.h
>> +++ b/xen/include/public/hvm/ioreq.h
>> @@ -24,6 +24,8 @@
>> #ifndef _IOREQ_H_
>> #define _IOR
On 09/11/16 14:39, Boris Ostrovsky wrote:
> This domctl is called when a VCPU is hot-(un)plugged to a guest (via
> 'xl vcpu-set'). While this currently is only intended to be needed by
> PVH guests we will call this domctl for all (x86) guests for consistency.
>
> Signed-off-by: Boris Ostrovsky
>
On 09/11/16 14:39, Boris Ostrovsky wrote:
> ACPI hotplug-related IO accesses (to GPE0 block) are handled
> by qemu for HVM guests. Since PVH guests don't have qemu these
> accesses will need to be procesed by the hypervisor.
>
> Because ACPI event model expects pm1a block to be present we
> need to
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 09 November 2016 14:40
> To: xen-devel@lists.xen.org
> Cc: jbeul...@suse.com; Andrew Cooper ;
> Wei Liu ; Ian Jackson ; Roger
> Pau Monne ; Boris Ostrovsky
> ; Paul Durrant
> Subject: [PATCH v2 08/11]
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 09 November 2016 14:40
> To: xen-devel@lists.xen.org
> Cc: jbeul...@suse.com; Andrew Cooper ;
> Wei Liu ; Ian Jackson ; Roger
> Pau Monne ; Boris Ostrovsky
> ; Paul Durrant
> Subject: [PATCH v2 07/11]
>>> On 09.11.16 at 15:28, wrote:
> On 11/09/2016 01:17 PM, Jan Beulich wrote:
> On 09.11.16 at 10:42, wrote:
>>> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>>> +{
>>> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>>> +
>>> +if ( vmcb->eventinj.fields
On 11/09/2016 09:48 AM, Julien Grall wrote:
> Hi Boris,
>
> On 09/11/16 14:39, Boris Ostrovsky wrote:
>> diff --git a/xen/include/public/arch-arm.h
>> b/xen/include/public/arch-arm.h
>> index bd974fb..b793774 100644
>> --- a/xen/include/public/arch-arm.h
>> +++ b/xen/include/public/arch-arm.h
>> @@
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 09 November 2016 14:40
> To: xen-devel@lists.xen.org
> Cc: jbeul...@suse.com; Andrew Cooper ;
> Wei Liu ; Ian Jackson ; Roger
> Pau Monne ; Boris Ostrovsky
> ; Julien Grall ; Paul
> Durrant
> Subject:
Hi Boris,
On 09/11/16 14:39, Boris Ostrovsky wrote:
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index bd974fb..b793774 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -383,6 +383,9 @@ typedef uint64_t xen_callback_t;
* should ins
Thanks it was really the problem of dts. I just followed the proceedings of
Ferger in Mailing lists who tried to bring up Dom0 in lager, and I got it
booted up. But now the problem is with rootfs. I am checking on that..
Thanks and regards,
George
On Tue, Nov 8, 2016 at 5:20 PM, Julien Grall wro
Signed-off-by: Boris Ostrovsky
---
Changes in v2:
* New patch
docs/misc/hvmlite.markdown | 12
1 file changed, 12 insertions(+)
diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 898b8ee..0045d22 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlit
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 the handler will be provided by a later patch.
Signed-off-by: Boris Ostrovsky
This is the method that will get invoked on an SCI.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Andrew Cooper
---
tools/libacpi/mk_dsdt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 2b8234d..780783e 10064
.. and update GPE0 registers.
Signed-off-by: Boris Ostrovsky
---
Changes in v2:
* Use has_ioreq_cpuhp() instead of ioreq_gmfn.mask==0 as check
for PVH guest
xen/arch/x86/domctl.c | 12
1 file changed, 12 insertions(+)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
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 insertions(+)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index e6
This domctl is called when a VCPU is hot-(un)plugged to a guest (via
'xl vcpu-set'). While this currently is only intended to be needed by
PVH guests we will call this domctl for all (x86) guests for consistency.
Signed-off-by: Boris Ostrovsky
Acked-by: Daniel De Graaf
---
Changes in v2:
* Added
Signed-off-by: Boris Ostrovsky
---
Changes in v2:
* HVM guests continue having the buttons
tools/firmware/hvmloader/util.c | 3 ++-
tools/libacpi/build.c | 2 ++
tools/libacpi/libacpi.h | 1 +
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/firmware/hvmloade
PVH guests do not have IOAPIC which typically generates an SCI. For
those guests SCI will be provided as a virtual interrupt.
We also move VIRQ_MCA definition out of xen-mca.h to
keep all x86-specific VIRQ_ARCH_* in one place.
Signed-off-by: Boris Ostrovsky
---
xen/include/asm-x86/event.h
This series adds support for ACPI-based VCPU hotplug for unprivileged
PVH guests.
New XEN_DOMCTL_set_avail_vcpus is introduced and is called during
guest creation and in response to 'xl vcpu-set' command. This domctl
updates GPE0's status and enable registers and sends an SCI to the
guest using (n
ACPI hotplug-related IO accesses (to GPE0 block) are handled
by qemu for HVM guests. Since PVH guests don't have qemu these
accesses will need to be procesed by the hypervisor.
Because ACPI event model expects pm1a block to be present we
need to have the hypervisor emulate it as well.
Signed-off-
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 hotplug.
Signed-off-by: Boris Ostrovsky
---
Changes in v2:
* Clarified
PM timer is not supported by PVH guests.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek Wilk
---
tools/firmware/hvmloader/util.c | 3 ++-
tools/libacpi/build.c | 5 +
tools/libacpi/libacpi.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a
flight 68018 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68018/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like
67978
test-amd64-
This run is configured for baseline tests only.
flight 68019 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68019/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 008e2ccf02e7be65b3a1b48a925f005115027d1c
baseline v
We are going to want to pass a whole slew of options to configure, and
hence to ts-xen-build. I think putting that in sg-run-job is
undesirable.
So, split out the ts-xen-build invocation into its own script.
Explicitly set the testid so that it does not change.
No significant functional change.
Amongst other things, we disable rombios which requires lzma.
Signed-off-by: Ian Jackson
---
ts-xen-build-rump | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ts-xen-build-rump b/ts-xen-build-rump
index 7ce3e73..9ea595b 100755
--- a/ts-xen-build-rump
+++ b/ts-xen-build-rump
@@ -2,5 +2,8 @
Between my last series for fixing the rump tests in osstest, xen.git
grew a dependency on liblzma which causese the rump build of the Xen
tools to fail.
Here I fix this by disabling lots of unwanted stuff by passing
appropriate --disable-whatever options to the xen.git configure
script.
I ran an
No functional change with existing callers.
Signed-off-by: Ian Jackson
---
ts-xen-build | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/ts-xen-build b/ts-xen-build
index 3e53d74..7dfcda7 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -37,7 +37,15 @@ while (@ARG
flight 102049 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102049/
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 11/09/2016 01:17 PM, Jan Beulich wrote:
On 09.11.16 at 10:42, wrote:
>> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>> +{
>> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>> +
>> +if ( vmcb->eventinj.fields.v )
>> +return false;
>> +
>> +
>>> On 09.11.16 at 13:01, wrote:
> Based on CVE-2015-7814 and commit 1ef01396fdff, ' arm: handle races between
> relinquish_memory and free_domheap_pages'..
> relinquish_memory() [xen/arch/arm/domain.c, arm code],
> when couldn't get a reference -- someone is freeing this page and has already
>
>>> On 09.11.16 at 13:28, wrote:
> The original code has a bug; eax and edx get unconditionally updated even when
> hvm_msr_read_intercept() doesn't return X86EMUL_OKAY.
>
> It is only by blind luck (vmce_rdmsr() eagerly initialising its msr_content
> pointer) that this isn't an information leak
Hi,
A bit of background: What I'm currently trying to do is to network
boot a first linux image in EFI mode (using UEFI network boot), then
from that image, kexec into Xen in EFI mode as well.
It's not working.
When you kexec into another linux in EFI mode, kexec actually passes
some more infos
flight 102058 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102058/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 102026
test-armhf-armhf-libvirt-qcow2 1
>>> On 09.11.16 at 12:49, wrote:
> On 09/11/16 11:32, Razvan Cojocaru wrote:
>> On 11/09/2016 01:17 PM, Jan Beulich wrote:
>> On 09.11.16 at 10:42, wrote:
@@ -259,6 +266,13 @@ struct vm_event_cpuid {
uint32_t _pad;
};
+struct vm_event_interrupt {
+uin
On 11/09/2016 04:04 PM, Jan Beulich wrote:
On 09.11.16 at 12:32, wrote:
>> On 11/09/2016 01:17 PM, Jan Beulich wrote:
>> On 09.11.16 at 10:42, wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)
>>> On 09.11.16 at 12:32, wrote:
> On 11/09/2016 01:17 PM, Jan Beulich wrote:
> On 09.11.16 at 10:42, wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)
>>> }
>>> }
>>>
>>> -/* Inject pendin
On 11/09/2016 01:17 PM, Jan Beulich wrote:
>> @@ -259,6 +266,13 @@ struct vm_event_cpuid {
>> > uint32_t _pad;
>> > };
>> >
>> > +struct vm_event_interrupt {
>> > +uint32_t vector;
>> > +uint32_t type;
>> > +uint32_t error_code;
>> > +uint64_t cr2;
>> > +};
> This being x86-
Hi,
On 09/11/16 00:39, Stefano Stabellini wrote:
On Wed, 28 Sep 2016, Andre Przywara wrote:
This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.
In addition this patch intro
Hi Stefano,
On 08/11/16 19:42, Stefano Stabellini wrote:
@@ -1189,7 +1194,10 @@ static int __init gicv2_init(void)
printk(XENLOG_WARNING
"GICv2: Adjusting CPU interface base to %#"PRIx64"\n",
cbase + aliased_offset);
-}
+} else if ( csize == SZ_12
flight 102045 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102045/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 102008
test-armhf-armhf-libvirt-xs
flight 102041 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102041/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 92983
test-amd64-amd64-libv
The original code has a bug; eax and edx get unconditionally updated even when
hvm_msr_read_intercept() doesn't return X86EMUL_OKAY.
It is only by blind luck (vmce_rdmsr() eagerly initialising its msr_content
pointer) that this isn't an information leak into guests.
While fixing this bug, reduce
Hello,
On 09/11/16 07:14, Dirk Behme wrote:
On 08.11.2016 16:41, Iurii Mykhalskyi wrote:
Hello Dirk,
I have made only single change - I recompile ATF to leave CPU in EL2
mode and reflash it.
Yes, this is what I meant with 'modifying firmware' ;)
You are loading Xen with U-Boot running in E
On 09/11/16 08:25, Jan Beulich wrote:
> There are two cases where this was wrong, albeit in a benign way (the
> compiler - according to my checking - didn't leverage the wrongness
> for any optimizations affecting overall outcome).
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
_
Hi,
Based on CVE-2015-7814 and commit 1ef01396fdff, ' arm: handle races between
relinquish_memory and free_domheap_pages'..
relinquish_memory() [xen/arch/arm/domain.c, arm code],
when couldn't get a reference -- someone is freeing this page and has already
committed to doing so, so no more to do
On 08/11/16 16:22, Roger Pau Monne wrote:
> Commit fac7f7 changed the value of ptr so that it points to the right memory
> area, taking the page offset into account, but failed to remove this when
> doing the unmap, which caused the region to not be unmapped. Fix this by not
> modifying ptr and ins
On 09/11/16 11:32, Razvan Cojocaru wrote:
> On 11/09/2016 01:17 PM, Jan Beulich wrote:
> On 09.11.16 at 10:42, 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_
On 09/11/16 08:31, Jan Beulich wrote:
On 08.11.16 at 19:36, wrote:
>> On 08/11/16 16:32, Jan Beulich wrote:
>> On 08.11.16 at 16:35, wrote:
Please find inline the design doc for further CPUID improvements, planned
for
development during the 4.9 timeframe.
>>> Looks good,
On 11/09/2016 01:17 PM, Jan Beulich wrote:
On 09.11.16 at 10:42, 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
>>> On 09.11.16 at 10:42, 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
flight 102062 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102062/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen bcb13635fa503113c981c6ea7423f930c1548452
baseline version:
xen 3ebe
Hi Wei, Ian,
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 should have one
commit per changed file... any opinion on that?
flight 102050 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102050/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 008e2ccf02e7be65b3a1b48a925f005115027d1c
baseline version:
ovmf fef15ecd20dd8db5bf0c3
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 102032 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102032/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 6 xen-bootfail REGR. vs. 100648
test-amd64-amd64-xl
>
> > 2. if previous p is 1 and it is in remapped mode, we can only set it to
> > remapped mode in _this_ function, setting it to posted mode is in
> > another function: pi_update_irte().
>
> Which may be part of the problem: Why are there two functions?
>
I think the reason is that pi_update_ir
>>> On 09.11.16 at 02:28, wrote:
> Any comment or suggestion to this patch set? That would be very appreciated.
Please be assured that this has not been forgotten, but there are
more important things to deal with, so it may take some more time
to get to this. That's both because this clearly is f
>>> On 08.11.16 at 19:36, wrote:
> On 08/11/16 16:32, Jan Beulich wrote:
> On 08.11.16 at 16:35, wrote:
>>> Please find inline the design doc for further CPUID improvements, planned
>>> for
>>> development during the 4.9 timeframe.
>> Looks good, just a couple of minor remarks.
>>
>>> ## Cha
On Tue, Nov 08, 2016 at 12:19:06PM -0500, Boris Ostrovsky wrote:
>
>
> On 11/08/2016 11:22 AM, Roger Pau Monne wrote:
> > Commit fac7f7 changed the value of ptr so that it points to the right memory
> > area, taking the page offset into account, but failed to remove this when
> > doing the unmap,
There are two cases where this was wrong, albeit in a benign way (the
compiler - according to my checking - didn't leverage the wrongness
for any optimizations affecting overall outcome).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_e
94 matches
Mail list logo
