flight 102097 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102097/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102045
test-armhf-armhf-libvirt
flight 102107 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102107/
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
Hi Thomas and Konrad,
On 11/11/2016 2:59 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon
wrote:
2016-11-07 07:38, Jianfeng Tan:
As some users are still using xen as the hypervisor, I suggest to
continue support for xen in DPDK. And from 16.11, I will be the
m
flight 102102 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102102/
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 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 at once. Thank you for
> > understanding m
On Thu, Nov 10, 2016 at 05:46:00PM +0100, Cédric Bosdonnat wrote:
> From the make documentation:
>
> "$* [...] If the target is `dir/a.foo.b' and the target pattern is
> `a.%.b' then the stem is `dir/foo'. In a static pattern rule, the
> stem is part of the file name that matched the `%' in the ta
On Thu, Nov 10, 2016 at 10:23:31AM +0100, Cédric Bosdonnat wrote:
> Gcc6 build reports misleading indentation as warnings. Fix a few
> warnings in stubdom.
>
> Signed-off-by: Cédric Bosdonnat
Applied.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On Wed, Nov 09, 2016 at 11:27:34AM +0100, Cedric Bosdonnat wrote:
> 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 maint
On Thu, Nov 10, 2016 at 01:01:38PM +, Julien Grall wrote:
> (CC Wei as release manager)
>
> On 10/11/16 08:30, Peng Fan wrote:
> >Hi Julien,
>
> Hi Peng,
>
> >On Tue, Nov 01, 2016 at 02:42:06PM +, Julien Grall wrote:
> >>Hi Peng,
> >>
> >>Sorry for the late answer.
> >>
> >>On 23/09/2016
On Tue, Nov 08, 2016 at 05:22:15PM +0100, 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
On Thu, Nov 10, 2016 at 01:01:38PM +, Julien Grall wrote:
>(CC Wei as release manager)
>
>On 10/11/16 08:30, Peng Fan wrote:
>>Hi Julien,
>
>Hi Peng,
>
>>On Tue, Nov 01, 2016 at 02:42:06PM +, Julien Grall wrote:
>>>Hi Peng,
>>>
>>>Sorry for the late answer.
>>>
>>>On 23/09/2016 03:55, Peng
flight 102086 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102086/
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 November 10, 2016 11:25 PM, Daniel De Graaf wrote:
>On 11/10/2016 04:23 AM, Cédric Bosdonnat wrote:
>> Gcc6 build reports misleading indentation as warnings. Fix a few
>> warnings in stubdom.
>>
>> Signed-off-by: Cédric Bosdonnat
>
>Acked-by: Daniel De Graaf
Acked-by: Quan Xu
Moving altp2m domain startup and teardown into altp2m_domain_init()
and altp2m_domain_teardown() respectively.
Moving hvm_altp2m_supported() check into functions that use it
for better readability.
Got rid of stray blanks after open paren after function names.
Defining _XEN_ASM_X86_P2M_H instead of
In hap_enable(), clean up memory leaks upon failure of altp2m_domain_init().
Comment the memory error handling to help match allocs with cleanups.
Consolidate the memory error handing into single code path.
---
xen/arch/x86/mm/hap/hap.c | 42 ++
1 file chang
The was requested in:
https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html
Renamed p2m_init_altp2m_helper() to p2m_init_altp2m_ept().
Signed-off-by: Paul Lai
Reviewed-by: Konrad Rzeszutek Wilk
---
xen/arch/x86/mm/p2m-ept.c | 39 +++
The altp2m clean work is motivated by the following URLs:
https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04454.html
Most of the work has been:
Lots of white space, indentation, and other coding style preference
corrections.
Lots of moving altp2m functions to the altp2m file.
Lo
Hi,
Thanks for helping me.
I'm trying lots of different things so maybe there are traces of older
tries i've done conflicting right now.
I'm planning on starting over again from the very beginning. I just wanna
know what tutorial follow. The one from the Wiki, from the mail thread or
another on
On Thu, 10 Nov 2016, Andre Przywara wrote:
> Hi,
>
> On 27/10/16 23:59, Stefano Stabellini wrote:
> > On Wed, 28 Sep 2016, Andre Przywara wrote:
> >> The number of LPIs on a host can be potentially huge (millions),
> >> although in practise will be mostly reasonable. So prematurely allocating
> >>
On Thu, 10 Nov 2016, Andre Przywara wrote:
> Hi,
>
> On 26/10/16 23:57, Stefano Stabellini wrote:
> > On Wed, 28 Sep 2016, Andre Przywara wrote:
> >> Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
> >> an EventID (the MSI payload or interrupt ID) to a pair of LPI number
> >
flight 102095 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102095/
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 Thu, 10 Nov 2016, Andre Przywara wrote:
> Hi,
>
> On 26/10/16 02:10, Stefano Stabellini wrote:
> > Hi Andre,
> >
> > Sorry for the late reply, I'll try to be faster for the next rounds of
> > review. The patch looks good for a first iteration. Some comments below.
>
> No worries and thanks fo
On Thu, 10 Nov 2016, Julien Grall wrote:
> Hi,
>
> 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
> > > > wrote:
> > > > > The INVALL command instructs
flight 102084 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102084/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 3 host-install(3)broken REGR. vs. 10206
flight 102087 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102087/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c52f00d6e1e14b9eaf5c5a58501f075d2a64920c
baseline version:
ovmf faabc5d49700a5042535f
On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon
wrote:
> 2016-11-07 07:38, Jianfeng Tan:
>> As some users are still using xen as the hypervisor, I suggest to
>> continue support for xen in DPDK. And from 16.11, I will be the
>> maintainer of all xen-related files.
>>
>> Signed-off-by: Jianfeng Tan
I mean is a nice GUI like VirtualBox.
On Mon, 11/7/16, Jason Long wrote:
Subject: Xen like VirtualBox
To: Xen-devel@lists.xen.org
Date: Monday, November 7, 2016, 10:18 AM
Hello.
Why Xen developer never think about a product like
VirtualBox? It
I mean is a nice GUI like VirtualBox.
On Mon, 11/7/16, Jason Long wrote:
Subject: Xen like VirtualBox
To: Xen-devel@lists.xen.org
Date: Monday, November 7, 2016, 10:18 AM
Hello.
Why Xen developer never think about a product like
VirtualBox? It
flight 102092 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102092/
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 11/10/2016 12:49 PM, David Vrabel wrote:
> On 10/11/16 17:47, Olaf Hering wrote:
>> On Thu, Nov 10, Boris Ostrovsky wrote:
>>
>>> Are you sure it's this patch that causes the failure?
>>>
>>> I commented out '| VM_IO' and still unable to boot with this option.
>> Yes, this works for me, sles12sp
On 11/10/2016 12:13 PM, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
>> On 11/10/2016 10:12 AM, Thomas Gleixner wrote:
>>> On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
By firmware you mean ACPI? It is most likely not available to PV guests.
>>> You either have to provide
On 10/11/16 17:47, Olaf Hering wrote:
> On Thu, Nov 10, Boris Ostrovsky wrote:
>
>> Are you sure it's this patch that causes the failure?
>>
>> I commented out '| VM_IO' and still unable to boot with this option.
>
> Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based:
>
> +++
On Thu, Nov 10, Boris Ostrovsky wrote:
> Are you sure it's this patch that causes the failure?
>
> I commented out '| VM_IO' and still unable to boot with this option.
Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based:
+++ b/drivers/xen/gntdev.c
@@ -804,7 +804,7 @@ static in
On 11/10/2016 11:42 AM, Olaf Hering wrote:
> On Thu, Nov 10, Boris Ostrovsky wrote:
>
>> Is this something new? Because this patch has been there for a year.
> It was just tested now, cycling through all the combinations for a
> disk=[]. Removing "direct-is-save" will use different code paths and t
Hi,
On 27/10/16 23:59, Stefano Stabellini wrote:
> On Wed, 28 Sep 2016, Andre Przywara wrote:
>> The number of LPIs on a host can be potentially huge (millions),
>> although in practise will be mostly reasonable. So prematurely allocating
>> an array of struct irq_desc's for each LPI is not an opt
On Thu, Nov 10, 2016 at 04:20:34PM +0100, Roger Pau Monné wrote:
> On Thu, Nov 10, 2016 at 08:53:05AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 10, 2016 at 11:39:08AM +0100, Roger Pau Monné wrote:
> > > On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Wed,
On Thu, Nov 10, 2016 at 09:37:19AM -0700, Jan Beulich wrote:
> >>> On 10.11.16 at 11:39, wrote:
> > On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote:
> >> > PCI memory BARs
> >> > ---
> >> >
> >
On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
> On 11/10/2016 10:12 AM, Thomas Gleixner wrote:
> > On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
> >> By firmware you mean ACPI? It is most likely not available to PV guests.
> > You either have to provide ACPI or MP tables. And either of those has to
> >
This run is configured for baseline tests only.
flight 68021 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68021/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c3c9892c3b4dafd1d0ccdc8e5e017d80e8c4361e
baseline v
From the make documentation:
"$* [...] If the target is `dir/a.foo.b' and the target pattern is
`a.%.b' then the stem is `dir/foo'. In a static pattern rule, the
stem is part of the file name that matched the `%' in the target
pattern."
The rule generating the c types files from the idl ones is n
On Thu, Nov 10, Boris Ostrovsky wrote:
> Is this something new? Because this patch has been there for a year.
It was just tested now, cycling through all the combinations for a
disk=[]. Removing "direct-is-save" will use different code paths and the
error is not seen.
Olaf
signature.asc
Descri
>>> On 10.11.16 at 11:39, wrote:
> On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote:
>> > PCI memory BARs
>> > ---
>> >
>> > PCI devices discovered by Xen will have it's BARs scanned in order to
On 11/10/2016 11:26 AM, Olaf Hering wrote:
> On Tue, Nov 10, Boris Ostrovsky wrote:
Perfect timing. This is from Nov. 10 2015.
>
>> Doing so will cause the grant to be unmapped and then, during
>> fault handling, the fault to be mistakenly treated as NUMA hint
>> fault.
>>
>> In addition, even if
On Tue, Nov 10, Boris Ostrovsky wrote:
> Doing so will cause the grant to be unmapped and then, during
> fault handling, the fault to be mistakenly treated as NUMA hint
> fault.
>
> In addition, even if those maps could partcipate in NUMA
> balancing, it wouldn't provide any benefit since we are
On 10/11/16 16:24, Boris Ostrovsky wrote:
> On 11/10/2016 11:12 AM, Jan Beulich wrote:
> On 10.11.16 at 15:55, wrote:
>>> On 10/11/16 14:50, Boris Ostrovsky wrote:
Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
APIC ID) with contents of that field on the proces
On 11/10/2016 11:12 AM, Jan Beulich wrote:
On 10.11.16 at 15:55, wrote:
>> On 10/11/16 14:50, 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
On 11/10/2016 06:01 PM, Tamas K Lengyel wrote:
>
>
> On Thu, Nov 10, 2016 at 6:33 AM, Razvan Cojocaru
> mailto:rcojoc...@bitdefender.com>> wrote:
>
> Hello Tamas, thanks for the review!
>
> On 11/10/2016 03:11 PM, Tamas K Lengyel wrote:
> > diff --git a/xen/include/asm-x86/vm_ev
On 10/11/16 17:14, Cedric Bosdonnat wrote:
> On Thu, 2016-11-10 at 15:49 +0100, Juergen Gross wrote:
>> On 10/11/16 14:11, Cédric Bosdonnat wrote:
>>> From the make documentation:
>>>
>>> "$* [...] If the target is `dir/a.foo.b' and the target pattern is
>>> `a.%.b' then the stem is `dir/foo'. In a
On Thu, 2016-11-10 at 15:49 +0100, Juergen Gross wrote:
> On 10/11/16 14:11, Cédric Bosdonnat wrote:
> > From the make documentation:
> >
> > "$* [...] If the target is `dir/a.foo.b' and the target pattern is
> > `a.%.b' then the stem is `dir/foo'. In a static pattern rule, the
> > stem is part of
>>> On 10.11.16 at 15:55, wrote:
> On 10/11/16 14:50, 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 I
On 11/10/2016 06:01 PM, Tamas K Lengyel wrote:
> On Thu, Nov 10, 2016 at 6:33 AM, Razvan Cojocaru
> mailto:rcojoc...@bitdefender.com>> wrote:
>
> Hello Tamas, thanks for the review!
>
> On 11/10/2016 03:11 PM, Tamas K Lengyel wrote:
> > diff --git a/xen/include/asm-x86/vm_event.h
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 instructions may end with
#GP(0) without that
Hi,
On 27/10/16 00:03, Stefano Stabellini wrote:
> On Wed, 28 Sep 2016, Andre Przywara wrote:
>> Instead of directly manipulating the tables in memory, an ITS driver
>> sends commands via a ring buffer to the ITS h/w to create or alter the
>> LPI mappings.
>> Allocate memory for that buffer and te
On 11/10/2016 05:59 PM, Andrew Cooper wrote:
@ -259,6 +266,14 @@ struct vm_event_cpuid {
>>> uint32_t _pad;
>>> };
>>>
>>> +struct vm_event_interrupt_x86 {
>>> +uint32_t vector;
>>> +uint32_t type;
>>> +uint32_t error_code;
>>> +u
On Thu, Nov 10, 2016 at 6:33 AM, Razvan Cojocaru
wrote:
> Hello Tamas, thanks for the review!
>
> On 11/10/2016 03:11 PM, Tamas K Lengyel wrote:
> > diff --git a/xen/include/asm-x86/vm_event.h
> > b/xen/include/asm-x86/vm_event.h
> > index ca73f99..38c624c 100644
> > --- a/xen/inc
On 10/11/16 15:53, Razvan Cojocaru wrote:
> On 11/10/2016 05:47 PM, Jan Beulich wrote:
> On 10.11.16 at 09:35, wrote:
>>> Changes since V1:
>>> - Modified the if() in hvm_do_resume() for readability.
>>> - Replaced hard tab with spaces.
>>> - Removed a local variable used only once.
>>> -
Hi,
On 27/10/16 00:55, Stefano Stabellini wrote:
> On Wed, 28 Sep 2016, Andre Przywara wrote:
>> To be able to easily send commands to the ITS, create the respective
>> wrapper functions, which take care of the ring buffer.
>> The first two commands we implement provide methods to map a collection
>>> On 10.11.16 at 09:35, wrote:
> Changes since V1:
> - Modified the if() in hvm_do_resume() for readability.
> - Replaced hard tab with spaces.
> - Removed a local variable used only once.
> - Moved cr2 assignment to the common part of the code.
> - Now listing the new event in the x86 vm_e
On 11/10/2016 05:47 PM, Jan Beulich wrote:
On 10.11.16 at 09:35, wrote:
>> Changes since V1:
>> - Modified the if() in hvm_do_resume() for readability.
>> - Replaced hard tab with spaces.
>> - Removed a local variable used only once.
>> - Moved cr2 assignment to the common part of the cod
>>> On 10.11.16 at 15:25, wrote:
> On 11/10/2016 03:35 AM, Razvan Cojocaru wrote:
>>
>> +bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>> +{
>> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
>> +return hvm_funcs.get_pending_event(v, info);
>> +}
>
> I believe it was Jan
Hi,
On 26/10/16 23:57, Stefano Stabellini wrote:
> On Wed, 28 Sep 2016, Andre Przywara wrote:
>> Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
>> an EventID (the MSI payload or interrupt ID) to a pair of LPI number
>> and collection ID, which points to the target CPU.
>> T
On 11/10/2016 10:12 AM, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
>> On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
>>> On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
>>>
I have found that your patch unfortunately does not improve the situation
for me. Here is an e
On Thu, Nov 10, 2016 at 08:53:05AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 10, 2016 at 11:39:08AM +0100, Roger Pau Monné wrote:
> > On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote:
> > > > In orde
Hi,
On 26/10/16 02:10, Stefano Stabellini wrote:
> Hi Andre,
>
> Sorry for the late reply, I'll try to be faster for the next rounds of
> review. The patch looks good for a first iteration. Some comments below.
No worries and thanks for the thorough review, much appreciated.
As you can see I too
On 11/10/2016 10:08 AM, Andrew Cooper wrote:
> On 10/11/16 15:05, Boris Ostrovsky wrote:
>> On 11/10/2016 09:55 AM, Andrew Cooper wrote:
>>> On 10/11/16 14:50, Boris Ostrovsky wrote:
Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
APIC ID) with contents of that field
On 11/10/2016 04:23 AM, Cédric Bosdonnat wrote:
Gcc6 build reports misleading indentation as warnings. Fix a few
warnings in stubdom.
Signed-off-by: Cédric Bosdonnat
Acked-by: Daniel De Graaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
htt
On 10/11/16 15:05, Boris Ostrovsky wrote:
> On 11/10/2016 09:55 AM, Andrew Cooper wrote:
>> On 10/11/16 14:50, 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
On 10/11/16 14:50, 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.
>
> We should be consist
On 11/10/2016 09:55 AM, Andrew Cooper wrote:
> On 10/11/16 14:50, 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 initia
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.
We should be consistent in how this value is reported, let's set
it to 0
flight 102077 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102077/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl 6 xen-boot fail in 101958 pass in 102077
test-amd64-amd64-amd64-pvgrub 6 x
On 10/11/16 14:11, Cédric Bosdonnat wrote:
> From the make documentation:
>
> "$* [...] If the target is `dir/a.foo.b' and the target pattern is
> `a.%.b' then the stem is `dir/foo'. In a static pattern rule, the
> stem is part of the file name that matched the `%' in the target
> pattern."
>
> T
On 11/10/2016 04:25 PM, Boris Ostrovsky wrote:
> On 11/10/2016 03:35 AM, Razvan Cojocaru wrote:
>>
>> +bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>> +{
>> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
>> +return hvm_funcs.get_pending_event(v, info);
>> +}
>
> I believ
On 11/10/2016 03:35 AM, Razvan Cojocaru wrote:
>
> +bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
> +{
> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
> +return hvm_funcs.get_pending_event(v, info);
> +}
I believe it was Jan who requested that cr2 update be factored out
On Wed, Nov 09, 2016 at 12:28:27PM +, 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 th
On Wed, Nov 09, 2016 at 01:25:20AM -0700, 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
Release-ac
On Thu, Nov 10, 2016 at 11:39:08AM +0100, Roger Pau Monné wrote:
> On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
> > 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
On 11/10/2016 03:41 PM, Julien Grall wrote:
> On 10/11/16 13:33, Razvan Cojocaru wrote:
>> I'm not sure about "occuring", the sources I've found online suggest my
>> spelling is correct, but perhaps this is a case of a word that can be
>> spelled in more ways, such as "color" and "colour":
>> https
On 10/11/16 13:33, Razvan Cojocaru wrote:
I'm not sure about "occuring", the sources I've found online suggest my
spelling is correct, but perhaps this is a case of a word that can be
spelled in more ways, such as "color" and "colour":
https://en.wiktionary.org/wiki/occuring
From the link:
"
Hello Tamas, thanks for the review!
On 11/10/2016 03:11 PM, Tamas K Lengyel wrote:
> diff --git a/xen/include/asm-x86/vm_event.h
> b/xen/include/asm-x86/vm_event.h
> index ca73f99..38c624c 100644
> --- a/xen/include/asm-x86/vm_event.h
> +++ b/xen/include/asm-x86/vm_event.h
>
From the make documentation:
"$* [...] If the target is `dir/a.foo.b' and the target pattern is
`a.%.b' then the stem is `dir/foo'. In a static pattern rule, the
stem is part of the file name that matched the `%' in the target
pattern."
The rule generating the c types files from the idl ones is n
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
> index ca73f99..38c624c 100644
> --- a/xen/include/asm-x86/vm_event.h
> +++ b/xen/include/asm-x86/vm_event.h
> @@ -27,6 +27,7 @@
> */
> struct arch_vm_event {
> uint32_t emulate_flags;
> +bool monitor_next_int
(CC Wei as release manager)
On 10/11/16 08:30, Peng Fan wrote:
Hi Julien,
Hi Peng,
On Tue, Nov 01, 2016 at 02:42:06PM +, Julien Grall wrote:
Hi Peng,
Sorry for the late answer.
On 23/09/2016 03:55, Peng Fan wrote:
On AArch64 SoCs, some IPs may only have the capability to access
32 bi
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 long as respective instructions may get used
in that case.
Signed-o
When introducing support for these instructions, adjustment for the
alignment check logic (generating #GP(0)) was overlooked.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4940,7 +4940,7 @@ x86_emulate(
{
(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 at once. Thank you for
understanding me.
And that’s why i need a small fix up and todo list.
I feel
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 at once. Thank you for
understanding me.
And that’s why i need a small fix up and todo list.
I feel familiar with ARM and c language and there’s no specific area yet.
I think that
flight 102082 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102082/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 102058
test-armhf-armhf-libvirt-qcow2 1
Hi,
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 wrote:
The INVALL command instructs an ITS to invalidate the configuration
data for all LPIs associated with a gi
On Wed, Nov 09, 2016 at 11:24:44AM -0500, Konrad Rzeszutek Wilk wrote:
> 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
>
On 10/11/16 10:54, Roger Pau Monné wrote:
> On Wed, Nov 09, 2016 at 06:51:49PM +, Andrew Cooper wrote:
>> On 09/11/16 15:59, Roger Pau Monné wrote:
>>> Low 1MB
>>> ---
>>>
>>> When booted with a legacy BIOS, the low 1MB contains firmware related data
>>> that should be identity mapped to th
On 10/11/16 00:49, Stefano Stabellini wrote:
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 init
On Wed, Nov 09, 2016 at 06:51:49PM +, Andrew Cooper wrote:
> On 09/11/16 15:59, Roger Pau Monné 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
> > memo
On 09/11/16 20:47, Pasi Kärkkäinen wrote:
> 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
>>> memo
On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
> 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 orde
Hello George,
On 09/11/16 14:47, George John wrote:
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..
May I ask you to upda
On Thu, Nov 03, 2016 at 02:48:26PM +0100, Daniel Kiper wrote:
> On Mon, Oct 24, 2016 at 03:57:22AM -0600, Jan Beulich wrote:
> > >>> On 24.10.16 at 11:03, wrote:
>
> [...]
>
> > > It looks that it is last thing which blocks whole patch series.
> >
> > I don't think so - Andrew has (not via mail) a
On 10.11.2016 10:25, Iurii Mykhalskyi wrote:
Hello Dirk,
On Thu, Nov 10, 2016 at 8:54 AM, Dirk Behme mailto:dirk.be...@de.bosch.com>> wrote:
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 Mykhals
flight 102076 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102076/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf faabc5d49700a5042535ff30a07e2c9577ed3cd8
baseline version:
ovmf c3c9892c3b4dafd1d0ccd
Hi Juergen,
Just resent the patch with the missing Signed-off-By and --cc-cmd
'./scripts/get_maintainers.pl'
--
Cedric
On Thu, 2016-11-10 at 09:42 +0100, Juergen Gross wrote:
> On 10/11/16 09:37, Cédric Bosdonnat wrote:
> > Gcc6 build reports misleading indentation as warnings. Fix a few
> > wa
1 - 100 of 108 matches
Mail list logo
