>>> On 17.06.16 at 08:08, wrote:
> On June 16, 2016 5:05 PM, Jan Beulich wrote:
>> >>> On 16.06.16 at 10:42, wrote:
>> > On June 02, 2016 7:07 PM, Jan Beulich wrote:
>> >> >>> On 01.06.16 at 11:05, wrote:
>> >> > +static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
>> >> >
>>> On 16.06.16 at 21:19, wrote:
> On 6/16/2016 5:24 PM, Jan Beulich wrote:
> On 16.06.16 at 16:06, wrote:
>>> --- a/xen/arch/x86/hvm/event.c
>>> +++ b/xen/arch/x86/hvm/event.c
>>> @@ -23,6 +23,7 @@
>>>
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #i
>>> On 16.06.16 at 22:10, wrote:
> On 6/16/2016 5:51 PM, Jan Beulich wrote:
> On 16.06.16 at 16:08, wrote:
>>> @@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
>>> }
>>> }
>>>
>>> +vm_event_vcpu_enter(v);
>> Why here?
> Why indeed. It made sense because monitor_wr
>>> On 16.06.16 at 22:20, wrote:
> On 6/16/2016 6:00 PM, Jan Beulich wrote:
> On 16.06.16 at 16:09, wrote:
>>> @@ -1432,18 +1430,16 @@ static void vmx_update_guest_cr(struct vcpu *v,
>>> unsigned int cr)
>>> if ( paging_mode_hap(v->domain) )
>>> {
>>> /* Man
flight 95825 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95825/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 3 host-install(3) broken REGR. vs. 95718
build-armhf
>>> On 16.06.16 at 22:27, wrote:
>> I.e. my plan was, once the backwards moves are small enough, to maybe
>> indeed compensate them by maintaining a global variable tracking
>> the most recently returned value. There are issues with such an
>> approach too, though: HT effects can result in one hyp
>>> On 17.06.16 at 09:27, wrote:
> flight 95825 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/95825/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-freebsd10-amd64 3 host-instal
>>> On 17.06.16 at 05:11, wrote:
> QEMU_TAG update to 698d6d6f8d095edadb0c23612b552a89dd3eee4c of traditional
> qemu in Config.mk, this commit is a branch stable-4.7 commit for qemu
> traditional. The master commit is 6e20809727261599e8527c456eb078c0e89139a1.
> It bring up a build error.
It wou
>>> On 17.06.16 at 07:26, wrote:
> In order to support reading another vcpu's mapped vcpu_runstate_info
> an indicator for an occurring update of the runstate information is
> needed.
>
> Add the possibility to activate setting this indicator in the highest
> bit of state_entry_time via a vm_assi
On June 17, 2016 3:01 PM, Jan Beulich wrote:
> >>> On 17.06.16 at 08:08, wrote:
>
> > On June 16, 2016 5:05 PM, Jan Beulich wrote:
> >> >>> On 16.06.16 at 10:42, wrote:
> >> > On June 02, 2016 7:07 PM, Jan Beulich wrote:
> >> >> >>> On 01.06.16 at 11:05, wrote:
> >> >> > +static void dev_inv
Hello Shannon,
On 17/06/16 04:29, Shannon Zhao wrote:
On 2016/6/6 19:40, Stefano Stabellini wrote:
ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
config file enables them, with default off.
While the configuration "acpi" already exists for HVM guest
configuration, do
Hi Wei,
On 16/06/16 12:20, Wei Liu wrote:
On Tue, Jun 07, 2016 at 12:00:26PM +0100, Julien Grall wrote:
I've read this sub-thread and the other thread in which Boris replied, I
think due to the fact that libxl has more information at hand and libxc
is intended to be simple, I think having the bu
>>> On 09.06.16 at 17:05, wrote:
On 09.06.16 at 16:27, wrote:
>> On 09/06/16 15:13, Jan Beulich wrote:
>> On 09.06.16 at 16:06, wrote:
On 09/06/16 13:31, Jan Beulich wrote:
On 09.06.16 at 13:34, wrote:
>> On 08/06/16 14:43, Jan Beulich wrote:
>>> Don't fetch CS ex
>>> On 08.06.16 at 14:48, wrote:
> 1: defer intercept handler registration
> 2: drop list lock
> 3: drop pci_msix_get_table_len()
> 4: use generic intercept handler in place of MMIO one
>
> Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-d
On 6/16/2016 6:16 PM, Jan Beulich wrote:
On 16.06.16 at 16:12, wrote:
Prepare for ARM implementation of control-register write vm-events by moving
X86-specific hvm_event_cr to the common-side.
Signed-off-by: Corneliu ZUZU
---
xen/arch/x86/hvm/event.c| 30
On 6/16/2016 7:02 PM, Tamas K Lengyel wrote:
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 014d9ba..05c3027 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -23,21 +23,18 @@
#include
#include
-static inline
-int vm_eve
On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
> On 6/16/2016 7:02 PM, Tamas K Lengyel wrote:
>>> diff --git a/xen/include/asm-arm/vm_event.h
>>> b/xen/include/asm-arm/vm_event.h
>>> index 014d9ba..05c3027 100644
>>> --- a/xen/include/asm-arm/vm_event.h
>>> +++ b/xen/include/asm-arm/vm_event.h
>>> @@
>>> On 17.06.16 at 10:25, wrote:
> On 6/16/2016 6:16 PM, Jan Beulich wrote:
>> And looking at all the uses of this variable I get the impression that
>> you really want a shorthand for &d->arch.monitor (if any such
>> helper variable is worthwhile to have here in the first place).
>
> Well, this
>>> On 17.06.16 at 10:15, wrote:
> On June 17, 2016 3:01 PM, Jan Beulich wrote:
>> >>> On 17.06.16 at 08:08, wrote:
>>
>> > On June 16, 2016 5:05 PM, Jan Beulich wrote:
>> >> >>> On 16.06.16 at 10:42, wrote:
>> >> > On June 02, 2016 7:07 PM, Jan Beulich wrote:
>> >> >> >>> On 01.06.16 at 11:
On Fri, Apr 15, 2016 at 04:56:26PM +0100, Andrew Cooper wrote:
> On 15/04/16 13:33, Daniel Kiper wrote:
> > reloc() is not called according to cdecl calling convention.
> > This makes confusion and does not scale well for more arguments.
> > And patch adding multiboot2 protocol support have to pass
On 6/16/2016 7:11 PM, Tamas K Lengyel wrote:
On Thu, Jun 16, 2016 at 8:07 AM, Corneliu ZUZU wrote:
For VM_EVENT_FLAG_DENY to work, the vcpu must be paused (sync = 1) until the
vm-event is handled. A vm-event response having VM_EVENT_FLAG_DENY flag set
should also set the VM_EVENT_FLAG_VCPU_PAUS
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, June 17, 2016 3:59 PM
> To: Hao, Xudong
> Cc: Wei Liu ; ian.jack...@eu.citrix.com; xen-
> de...@lists.xenproject.org
> Subject: Re: [Xen-devel] qemu-traditional build problem for Xen 4.7.0 RC6
>
> >>> On
+ arm/amd maintainers..
On June 01, 2016 5:05 PM, Xu, Quan wrote:
> If Device-TLB flush timed out, we hide the target ATS device immediately and
> crash the domain owning this ATS device. If impacted domain is hardware
> domain, just throw out a warning.
>
> By hiding the device, we make sure it
Hello,
On 16/06/16 15:08, Corneliu ZUZU wrote:
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d31f821..ba248c8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -251,6 +252
flight 95831 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95831/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927
build-i
On Tue, May 24, 2016 at 06:52:39AM -0600, Jan Beulich wrote:
> >>> On 24.05.16 at 14:28, wrote:
> > On Tue, May 24, 2016 at 03:05:06AM -0600, Jan Beulich wrote:
> >> >>> On 15.04.16 at 14:33, wrote:
> >> > --- /dev/null
> >> > +++ b/xen/arch/x86/boot/build32.lds
> >> > @@ -0,0 +1,49 @@
> >> > +/*
In case the word size of the domU and qemu running the qdisk backend
differ BLKIF_OP_DISCARD will not work reliably, as the request
structure in the ring have different layouts for different word size.
Correct this by copying the request structure in case of different
word size element by element
On Fri, 17 Jun 2016, Julien Grall wrote:
> Hello Shannon,
>
> On 17/06/16 04:29, Shannon Zhao wrote:
> > On 2016/6/6 19:40, Stefano Stabellini wrote:
> > > ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
> > > config file enables them, with default off.
> > While the confi
On 6/16/2016 7:17 PM, Tamas K Lengyel wrote:
On Thu, Jun 16, 2016 at 8:08 AM, Corneliu ZUZU wrote:
In an effort to improve on the vm-event interface, we introduce a new function
called vm_event_vcpu_enter. Its significance is that of a "final touch" vCPU
function - i.e. it should be called by i
On 6/16/2016 7:27 PM, Tamas K Lengyel wrote:
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 1fec412..1e5445f 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -20,7 +20,6 @@
*/
#include
-#include
int arch_monitor_domctl_event(struct domain *d,
>>> On 17.06.16 at 11:14, wrote:
> In case the word size of the domU and qemu running the qdisk backend
> differ BLKIF_OP_DISCARD will not work reliably, as the request
> structure in the ring have different layouts for different word size.
>
> Correct this by copying the request structure in cas
On 17/06/16 09:36, Razvan Cojocaru wrote:
> On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
>> On 6/16/2016 7:02 PM, Tamas K Lengyel wrote:
diff --git a/xen/include/asm-arm/vm_event.h
b/xen/include/asm-arm/vm_event.h
index 014d9ba..05c3027 100644
--- a/xen/include/asm-arm/vm_event.
>>> On 17.06.16 at 10:41, wrote:
> On Fri, Apr 15, 2016 at 04:56:26PM +0100, Andrew Cooper wrote:
>> On 15/04/16 13:33, Daniel Kiper wrote:
>> > reloc() is not called according to cdecl calling convention.
>> > This makes confusion and does not scale well for more arguments.
>> > And patch adding
On 17/06/16 11:26, Jan Beulich wrote:
On 17.06.16 at 11:14, wrote:
>> In case the word size of the domU and qemu running the qdisk backend
>> differ BLKIF_OP_DISCARD will not work reliably, as the request
>> structure in the ring have different layouts for different word size.
>>
>> Correct t
On 13/06/16 12:14, Philipp Hahn wrote:
> Am 13.06.2016 um 12:15 schrieb George Dunlap:
>> On Fri, Jun 10, 2016 at 4:22 PM, Philipp Hahn wrote:
>>> while trying to live migrate some VMs from an xen-4.1.6.1 host "xc_save"
>>> crashes with a segmentation fault in tools/libxc/xc_domain_save.c:1141
>>>
>>> On 17.06.16 at 10:36, wrote:
> On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
>> Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
>> Since you already have a patch for that I guess it's ok to remove those
>> comments and leave the rest as it is and merge later when one of t
>>> On 17.06.16 at 11:29, wrote:
> Staging is now open for Xen 4.8 submissions.
Just to clarify - not fully. Intrusive changes (with a higher risk of
causing backporting conflicts for eventual changes still wanting to
go into 4.7) were agreed to not get put in yet.
Jan
On 06/17/2016 12:33 PM, Jan Beulich wrote:
On 17.06.16 at 10:36, wrote:
>> On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
>>> Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
>>> Since you already have a patch for that I guess it's ok to remove those
>>> comments and leave
On 09/06/16 16:05, Jan Beulich wrote:
On 09.06.16 at 16:27, wrote:
>> On 09/06/16 15:13, Jan Beulich wrote:
>> On 09.06.16 at 16:06, wrote:
On 09/06/16 13:31, Jan Beulich wrote:
On 09.06.16 at 13:34, wrote:
>> On 08/06/16 14:43, Jan Beulich wrote:
>>> Don't fetch C
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 17 June 2016 10:26
> To: Juergen Gross
> Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
> de...@nongnu.org; kra...@redhat.com
> Subject: Re: [Xen-devel] [PATCH v2
On 16/06/16 10:40, Jan Beulich wrote:
> Various Linux versions allocate (partial) per-CPU data for all of them,
> as there is no indication in MADT whether they're hotpluggable. That's
> a little wasteful in terms of resource consumption especially for
> - guests with not overly much memory assigne
>>> On 17.06.16 at 11:36, wrote:
> On 06/17/2016 12:33 PM, Jan Beulich wrote:
> On 17.06.16 at 10:36, wrote:
>>> On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
Since you already have a patch for that I guess it's o
>>> On 17.06.16 at 11:31, wrote:
> On 17/06/16 11:26, Jan Beulich wrote:
> On 17.06.16 at 11:14, wrote:
>>> In case the word size of the domU and qemu running the qdisk backend
>>> differ BLKIF_OP_DISCARD will not work reliably, as the request
>>> structure in the ring have different layouts
On 06/17/2016 12:40 PM, Jan Beulich wrote:
On 17.06.16 at 11:36, wrote:
>> On 06/17/2016 12:33 PM, Jan Beulich wrote:
>> On 17.06.16 at 10:36, wrote:
On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
> Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
> Since
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Juergen Gross
> Sent: 17 June 2016 10:31
> To: Jan Beulich
> Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
> de...@nongnu.org; kra...@redhat.com
> Subject: Re: [Xen-devel] [PATCH v2
On 17/06/16 11:37, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
>> Beulich
>> Sent: 17 June 2016 10:26
>> To: Juergen Gross
>> Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
>> de...@nongnu.org; kra...@r
> -Original Message-
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: 17 June 2016 10:46
> To: Paul Durrant; Jan Beulich
> Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
> de...@nongnu.org; kra...@redhat.com
> Subject: Re: [Xen-devel] [PATCH v2] xen: fix qdisk BLKIF_OP_D
>>> On 17.06.16 at 11:37, wrote:
> On 09/06/16 16:05, Jan Beulich wrote:
> On 09.06.16 at 16:27, wrote:
>>> On 09/06/16 15:13, Jan Beulich wrote:
>>> On 09.06.16 at 16:06, wrote:
> On 09/06/16 13:31, Jan Beulich wrote:
> On 09.06.16 at 13:34, wrote:
>>> On 08/06/16 14:43
On Thu, Jun 16, 2016 at 02:47:51PM -0700, Dongli Zhang wrote:
>
> > I suggest pasting in Olaf's exact error message here.
> >
> > To avoid extra round trip, I propose updating the commit message as
> > followed:
> >
> > Initialise j to 0 to make some versions of gcc (e.g., gcc4.5/4.3)
> > ha
>>> On 17.06.16 at 11:06, wrote:
> On Tue, May 24, 2016 at 06:52:39AM -0600, Jan Beulich wrote:
>> >>> On 24.05.16 at 14:28, wrote:
>> > On Tue, May 24, 2016 at 03:05:06AM -0600, Jan Beulich wrote:
>> >> >>> On 15.04.16 at 14:33, wrote:
>> >> > + /DISCARD/ : {
>> >> > +/*
>> >> > +
On 16/06/16 10:40, Jan Beulich wrote:
> The IO-APIC address has variable bits determined by the PCI-to-ISA
> bridge, and the IO-APIC version should be read from the IO-APIC. (Note
> that there's still implicit rather than explicit agreement on the
> IO-APIC base address between qemu and the hypervi
On 17/06/16 11:50, Paul Durrant wrote:
>> -Original Message-
>> From: Juergen Gross [mailto:jgr...@suse.com]
>> Sent: 17 June 2016 10:46
>> To: Paul Durrant; Jan Beulich
>> Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
>> de...@nongnu.org; kra...@redhat.com
>> Subject: Re: [X
On Thu, Jun 16, 2016 at 09:25:20AM -0400, Boris Ostrovsky wrote:
> On 06/16/2016 07:20 AM, Wei Liu wrote:
> > On Tue, Jun 07, 2016 at 12:00:26PM +0100, Julien Grall wrote:
> >> Hello Shannon,
> >>
> >> On 07/06/16 02:07, Shannon Zhao wrote:
> >>> On 2016/6/6 23:48, Julien Grall wrote:
> On 06/
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Juergen Gross
> Sent: 17 June 2016 11:08
> To: Paul Durrant; Jan Beulich
> Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
> de...@nongnu.org; kra...@redhat.com
> Subject: Re: [Xen-de
On 16/06/16 10:55, Jan Beulich wrote:
>> Previously in the 2nd version, I used p2m_change_entry_type_global() to
>> reset the
>> outstanding p2m_ioreq_server entries back to p2m_ram_rw asynchronously after
>> the de-registration. But we realized later that this approach means we
>> can not suppor
>>> On 17.06.16 at 12:08, wrote:
> On 17/06/16 11:50, Paul Durrant wrote:
>>> -Original Message-
>>> From: Juergen Gross [mailto:jgr...@suse.com]
>>> Sent: 17 June 2016 10:46
>>> To: Paul Durrant; Jan Beulich
>>> Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
>>> de...@nongnu
>>> On 17.06.16 at 12:05, wrote:
> On 16/06/16 10:40, Jan Beulich wrote:
>> The IO-APIC address has variable bits determined by the PCI-to-ISA
>> bridge, and the IO-APIC version should be read from the IO-APIC. (Note
>> that there's still implicit rather than explicit agreement on the
>> IO-APIC b
instead of just the first scheduler we find in the array.
In fact, right now, if someone makes a typo when passing
the "sched=" command line option to Xen, we (with all
schedulers configured in) pick ARINC653, which is most
likely not what one would expect.
Go for the default scheduler instead.
On Fri, Jun 17, 2016 at 04:04:20AM -0600, Jan Beulich wrote:
> >>> On 17.06.16 at 11:06, wrote:
> > On Tue, May 24, 2016 at 06:52:39AM -0600, Jan Beulich wrote:
> >> >>> On 24.05.16 at 14:28, wrote:
> >> > On Tue, May 24, 2016 at 03:05:06AM -0600, Jan Beulich wrote:
> >> >> >>> On 15.04.16 at 14:
On 6/16/2016 7:49 PM, Julien Grall wrote:
Hello Corneliu,
On 16/06/16 15:13, Corneliu ZUZU wrote:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 8c50685..af61ac3 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#
On 6/16/2016 7:55 PM, Tamas K Lengyel wrote:
On Thu, Jun 16, 2016 at 8:12 AM, Corneliu ZUZU wrote:
Prepare for ARM implementation of control-register write vm-events by moving
X86-specific hvm_event_cr to the common-side.
Signed-off-by: Corneliu ZUZU
---
xen/arch/x86/hvm/event.c| 30
On Wed, Jun 15, 2016 at 09:46:45AM +0800, wj zhou wrote:
> Hi,
>
> Thanks a lot for your reply!
>
> On Tue, Jun 14, 2016 at 11:02 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Tue, Jun 14, 2016 at 08:21:16AM +0800, wj zhou wrote:
> >> Hello all,
> >
> > Hey,
> >
> > CC-ing Daniel, and Dave.
> >>
> >>
On 17/06/16 12:15, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
>> Juergen Gross
>> Sent: 17 June 2016 11:08
>> To: Paul Durrant; Jan Beulich
>> Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
>> de...@nongnu
On 6/16/2016 11:33 PM, Razvan Cojocaru wrote:
On 06/16/16 23:10, Corneliu ZUZU wrote:
On 6/16/2016 5:51 PM, Jan Beulich wrote:
On 16.06.16 at 16:08, wrote:
@@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
}
}
+vm_event_vcpu_enter(v);
Why here?
Why indeed. It m
On Tue, Jun 14, 2016 at 02:17:38PM +0100, Wei Liu wrote:
>
> > docs: honour XEN_DUMP_DIR
>
> This is acked but we would like to wait a bit.
>
> > build: introduce XEN_RUN_STORED
>
> This is not yet acked.
>
> > hotplug/Linux: honour XEN_RUN_STORED
> > libxenstore: honour XEN_RUN_STORED
On Tue, Jun 14, 2016 at 12:05:35PM +0200, Juergen Gross wrote:
> On 14/06/16 11:58, Wei Liu wrote:
> > On Tue, Jun 14, 2016 at 10:56:52AM +0100, Wei Liu wrote:
> >> On Tue, Jun 14, 2016 at 11:01:50AM +0200, Dario Faggioli wrote:
> >>> On Tue, 2016-06-14 at 06:30 +0200, Juergen Gross wrote:
> W
On 6/17/2016 10:06 AM, Jan Beulich wrote:
On 16.06.16 at 21:19, wrote:
On 6/16/2016 5:24 PM, Jan Beulich wrote:
On 16.06.16 at 16:06, wrote:
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
On Fri, Jun 03, 2016 at 08:25:05PM +0100, Wei Liu wrote:
> On Tue, May 31, 2016 at 01:02:53PM +0800, Shannon Zhao wrote:
> > From: Shannon Zhao
> >
> > It should be xc_dom_devicetree_mem instead of xc_dom_devicetree_file.
> >
> > Signed-off-by: Shannon Zhao
>
> Acked-by: Wei Liu
>
I've push
> -Original Message-
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: 17 June 2016 11:40
> To: Paul Durrant; Jan Beulich
> Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
> de...@nongnu.org; kra...@redhat.com
> Subject: Re: [Xen-devel] [PATCH v2] xen: fix qdisk BLKIF_OP_D
On 17/06/16 11:31, Dario Faggioli wrote:
> instead of just the first scheduler we find in the array.
>
> In fact, right now, if someone makes a typo when passing
> the "sched=" command line option to Xen, we (with all
> schedulers configured in) pick ARINC653, which is most
> likely not what one wo
Wei Liu (2):
xen/kernel: document 'C' in print_tainted
xen: make available hvm_fep to non-debug build as well
docs/misc/xen-command-line.markdown | 8 ++--
xen/arch/x86/Kconfig| 14 ++
xen/arch/x86/hvm/hvm.c | 28 ++--
xen/
Originally hvm_fep was guarded by NDEBUG, which means it was only
available to debug builds.
However there is value to have it for non-debug builds as well. User can
use that to run tests in setup that replicates production setup.
Make it clear with a sync_console style warning that this option c
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/common/kernel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/common/kernel.c
On 6/17/2016 10:17 AM, Jan Beulich wrote:
On 16.06.16 at 22:10, wrote:
On 6/16/2016 5:51 PM, Jan Beulich wrote:
On 16.06.16 at 16:08, wrote:
@@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
}
}
+vm_event_vcpu_enter(v);
Why here?
Why indeed. It made sense bec
The qdisk implementation is using the native xenbus protocol only in
case of no protocol specified at all. As using the explicit 32- or
64-bit protocol is slower than the native one due to copying requests
not by memcpy but element for element, this is not optimal.
Correct this by using the native
On 6/17/2016 10:20 AM, Jan Beulich wrote:
On 16.06.16 at 22:20, wrote:
On 6/16/2016 6:00 PM, Jan Beulich wrote:
On 16.06.16 at 16:09, wrote:
@@ -1432,18 +1430,16 @@ static void vmx_update_guest_cr(struct vcpu *v,
unsigned int cr)
if ( paging_mode_hap(v->domain) )
{
flight 95853 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95853/
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 12
>>> On 17.06.16 at 13:13, wrote:
> On 6/17/2016 10:17 AM, Jan Beulich wrote:
>> (And to be clear, I much appreciate any form of reduction of the
>> sometimes extremely long lists of #include-s, just not [apparently
>> or really] randomly mixed with other, substantial changes. That's
>> namely beca
On 6/17/2016 11:38 AM, Jan Beulich wrote:
On 17.06.16 at 10:25, wrote:
On 6/16/2016 6:16 PM, Jan Beulich wrote:
And looking at all the uses of this variable I get the impression that
you really want a shorthand for &d->arch.monitor (if any such
helper variable is worthwhile to have here in the
>>> On 17.06.16 at 13:05, wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -59,6 +59,20 @@ config BIGMEM
>
> If unsure, say N.
>
> +config HVM_FEP
> + bool "HVM Forced Emulation Prefix support"
And no "if EXPERT"?
> @@ -95,9 +96,9 @@ unsigned long __section("
On 6/17/2016 11:55 AM, Julien Grall wrote:
Hello,
On 16/06/16 15:08, Corneliu ZUZU wrote:
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d31f821..ba248c8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#incl
On 6/17/2016 12:28 AM, Julien Grall wrote:
On 16/06/2016 20:24, Corneliu ZUZU wrote:
On 6/16/2016 5:26 PM, Julien Grall wrote:
Hi Julien. Yes, I agree that it's complex, I would have preferred to
split it up too and I actually tried, but the changes are tightly
coupled and they don't seem to b
On 06/17/2016 02:00 AM, Jan Beulich wrote:
On 16.06.16 at 18:49, wrote:
>> On 06/16/2016 05:40 AM, Jan Beulich wrote:
>>> The IO-APIC address has variable bits determined by the PCI-to-ISA
>>> bridge, and the IO-APIC version should be read from the IO-APIC. (Note
>>> that there's still implic
On 6/17/2016 2:27 PM, Jan Beulich wrote:
On 17.06.16 at 13:13, wrote:
On 6/17/2016 10:17 AM, Jan Beulich wrote:
(And to be clear, I much appreciate any form of reduction of the
sometimes extremely long lists of #include-s, just not [apparently
or really] randomly mixed with other, substantial
flight 95836 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95836/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 95164
test-amd64-amd64-qemuu
Hello Corneliu,
On 17/06/16 11:36, Corneliu ZUZU wrote:
On 6/16/2016 7:49 PM, Julien Grall wrote:
On 16/06/16 15:13, Corneliu ZUZU wrote:
[...]
Please mention that PRRR and NMRR are aliased to respectively MAIR0
and MAIR1. This will avoid to spend time trying to understanding why
the spec s
Hello,
On 17/06/16 12:40, Corneliu ZUZU wrote:
On 6/17/2016 11:55 AM, Julien Grall wrote:
On 16/06/16 15:08, Corneliu ZUZU wrote:
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d31f821..ba248c8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -19,6 +19,7 @@
On 17/06/16 10:15, Stefano Stabellini wrote:
On Fri, 17 Jun 2016, Julien Grall wrote:
Hello Shannon,
On 17/06/16 04:29, Shannon Zhao wrote:
On 2016/6/6 19:40, Stefano Stabellini wrote:
ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
config file enables them, with de
Hi Quan,
On 17/06/16 09:51, Xu, Quan wrote:
+ arm/amd maintainers..
On June 01, 2016 5:05 PM, Xu, Quan wrote:
If Device-TLB flush timed out, we hide the target ATS device immediately and
crash the domain owning this ATS device. If impacted domain is hardware
domain, just throw out a warning.
On Fri, Jun 17, 2016 at 05:34:07AM -0600, Jan Beulich wrote:
> >>> On 17.06.16 at 13:05, wrote:
> > --- a/xen/arch/x86/Kconfig
> > +++ b/xen/arch/x86/Kconfig
> > @@ -59,6 +59,20 @@ config BIGMEM
> >
> > If unsure, say N.
> >
> > +config HVM_FEP
> > + bool "HVM Forced Emulation Prefix s
flight 95833 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95833/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
> On Jun 17, 2016, at 5:31 AM, Dario Faggioli wrote:
>
> instead of just the first scheduler we find in the array.
>
> In fact, right now, if someone makes a typo when passing
> the "sched=" command line option to Xen, we (with all
> schedulers configured in) pick ARINC653, which is most
> like
On 17/06/16 12:05, Wei Liu wrote:
> Originally hvm_fep was guarded by NDEBUG, which means it was only
> available to debug builds.
>
> However there is value to have it for non-debug builds as well. User can
> use that to run tests in setup that replicates production setup.
>
> Make it clear with a
flight 95858 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95858/
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 12
On 17/06/16 12:34, Jan Beulich wrote:
On 17.06.16 at 13:05, wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -59,6 +59,20 @@ config BIGMEM
>>
>>If unsure, say N.
>>
>> +config HVM_FEP
>> +bool "HVM Forced Emulation Prefix support"
> And no "if EXPERT"?
On 6/17/16 5:31 AM, Dario Faggioli wrote:
> instead of just the first scheduler we find in the array.
>
> In fact, right now, if someone makes a typo when passing
> the "sched=" command line option to Xen, we (with all
> schedulers configured in) pick ARINC653, which is most
> likely not what one
On 17/06/16 11:31, Dario Faggioli wrote:
> instead of just the first scheduler we find in the array.
>
> In fact, right now, if someone makes a typo when passing
> the "sched=" command line option to Xen, we (with all
> schedulers configured in) pick ARINC653, which is most
> likely not what one w
Signed-off-by: Wei Liu
---
tests/fep/Makefile | 12
tests/fep/main.c | 31 +++
2 files changed, 43 insertions(+)
create mode 100644 tests/fep/Makefile
create mode 100644 tests/fep/main.c
diff --git a/tests/fep/Makefile b/tests/fep/Makefile
new file mo
>>> On 17.06.16 at 13:51, wrote:
> On 06/17/2016 02:00 AM, Jan Beulich wrote:
> On 16.06.16 at 18:49, wrote:
>>> On 06/16/2016 05:40 AM, Jan Beulich wrote:
The IO-APIC address has variable bits determined by the PCI-to-ISA
bridge, and the IO-APIC version should be read from the IO-A
On Fri, Jun 17, 2016 at 12:31:00PM +0200, Dario Faggioli wrote:
> instead of just the first scheduler we find in the array.
>
> In fact, right now, if someone makes a typo when passing
> the "sched=" command line option to Xen, we (with all
> schedulers configured in) pick ARINC653, which is most
1 - 100 of 168 matches
Mail list logo
