On 04/12/16 07:31, Jan Beulich wrote:
Tamas K Lengyel 04/11/16 9:47 PM >>>
>> --- a/xen/include/public/vm_event.h
>> +++ b/xen/include/public/vm_event.h
>> @@ -166,6 +166,31 @@ struct vm_event_regs_x86 {
> >uint32_t _pad;
> >};
> >
>> +struct vm_event_regs_arm {
>> +uint32_t r0;
>>
>>> Tamas K Lengyel 04/11/16 9:47 PM >>>
>--- a/xen/include/public/vm_event.h
>+++ b/xen/include/public/vm_event.h
>@@ -166,6 +166,31 @@ struct vm_event_regs_x86 {
>uint32_t _pad;
>};
>
>+struct vm_event_regs_arm {
>+uint32_t r0;
>+uint32_t r1;
>+uint32_t r2;
>+uint32_t r3;
On 04/11/16 22:18, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 11, 2016 at 07:41:54PM +0300, Razvan Cojocaru wrote:
>> This patch only allows introspection-related MSR write events to
>> be sent out, improving performance. Should additional events be
>> required, they can then simply be added to the
flight 90906 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/90906/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 60684
build-amd6
Thanks Xu. I will do as desired about cross messaging.
i need it because i exactly want to know that which part of the scheduler's
corde (credit), takes effect from this feature. because it is important to me
knowing that where would be trade off between idle state and doing load
balancing, whi
在 2016/4/11 19:27, Wei Liu 写道:
On Mon, Apr 11, 2016 at 09:42:57AM +0800, Zhenzhong Duan wrote:
It's tool's duty to pass a correct cpumap to XEN. On a host with less than
64
CPUS, it just shows below error.
[root@localhost /]# xm vcpu-pin 3 all all
Error: Cannot pin vcpu: 0 to cpu: [0, 1, 2, 3,
George,
In this discussion, most of them are memory-related problems. Your comments are
valuable.
If you have read this thread, could you give me some feedback? I really
appreciate your precious advice.
Quan
On March 31, 2016 5:06pm, Quan, Xu wrote:
> All,
>
> Here is a summary of my invest
flight 90907 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/90907/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saver
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Monday, April 11, 2016 6:54 PM
> To: Samuel Thibault ; Wei Liu
> ; Hao, Xudong ; Konrad
> Rzeszutek Wilk ; xen-devel@lists.xen.org;
> stefano.stabell...@eu.citrix.com; Anthony PERARD
> Subject: Re: [Xen-devel] pv-gru
On April 12, 2016 12:35am, Jan Beulich wrote:
> >>> On 11.04.16 at 05:27, wrote:
> > On April 11, 2016 11:10am, wrote:
> >> On March 29, 2016 3:37pm, Jan Beulich wrote:
> >> > >>> On 25.03.16 at 10:27, wrote:
> >> > > On March 18, 2016 6:20pm, wrote:
> >> > >> >>> On 17.03.16 at 07:54, wrote
On 2016/4/11 22:07, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 11, 2016 at 02:33:33PM +0100, Julien Grall wrote:
>> The SPCR does not specify if the interrupt is edge or level triggered.
>> So the configuration needs to be hardcoded in the code.
>>
>> Based on the PL011 TRM (see 2.2.8 in ARM DDI
flight 90847 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/90847/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 3 host-install(3)broken REGR. vs. 86491
build-amd64-libvirt
On Apr 11, 2016 11:41 AM, "Jan Beulich" wrote:
>
> >>> On 10.04.16 at 04:45, wrote:
> > On Sat, Apr 09, 2016 at 10:36:00PM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Apr 07, 2016 at 09:43:38AM -0600, Jan Beulich wrote:
> >> > >>> On 07.04.16 at 05:09, wrote:
> >> > >> > +uint8_t *old_p
flight 91017 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91017/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfail like 90970
Tests which did not suc
flight 90848 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/90848/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 10 guest-start fail REGR. vs. 86454
test-amd64-i386-fre
From: Tamas K Lengyel
The ARM SMC instructions are already configured to trap to Xen by default. In
this patch we allow a user-space process in a privileged domain to receive
notification of when such event happens through the vm_event subsystem.
This patch will likely needs to be broken up into
The following BUG_ON error was reported on QEMU/i386:
kernel BUG at arch/x86/mm/physaddr.c:79!
Call Trace:
phys_mem_access_prot_allowed
mmap_mem
? mmap_region
mmap_region
do_mmap
vm_mmap_pgoff
SyS_mmap_pgoff
do_int80_syscall_32
entry_INT80_32
after commit edfe63ec97ed ("x86/
On Mon, Apr 11, 2016 at 07:41:54PM +0300, Razvan Cojocaru wrote:
> This patch only allows introspection-related MSR write events to
> be sent out, improving performance. Should additional events be
> required, they can then simply be added to the list of
> vmx_introspection_force_enabled_msrs[].
>
flight 90993 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/90993/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 90970
Regressions wh
branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen
On Mon, Apr 11, 2016 at 02:21:55PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 11, 2016 at 11:26:05AM -0600, Jan Beulich wrote:
> > >>> On 11.04.16 at 19:08, wrote:
> > > If the system admin continously tried to unload and load the patchset
> > > then we certainly would spam.
> > >
> > > Bu
flight 90845 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/90845/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
On Mon, Apr 11, 2016 at 11:26:05AM -0600, Jan Beulich wrote:
> >>> On 11.04.16 at 19:08, wrote:
> > If the system admin continously tried to unload and load the patchset
> > then we certainly would spam.
> >
> > But the 'loading' is (or ought to) be a single event. The applying
> > or reverting m
On Mon, 11 Apr 2016, Juergen Gross wrote:
> Document the interface between qemu and libxl regarding backends
> supported by qemu.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Stefano Stabellini
> v2: - replace variable Xenstore path parts () with bash-like syntax
> ($XYZ) as requested
On Mon, 11 Apr 2016, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 11, 2016 at 02:33:33PM +0100, Julien Grall wrote:
> > The SPCR does not specify if the interrupt is edge or level triggered.
> > So the configuration needs to be hardcoded in the code.
> >
> > Based on the PL011 TRM (see 2.2.8 in ARM
On Mon, 11 Apr 2016, Julien Grall wrote:
> Since the ACPI 6.0 errata document [1], the first entry in the MADT
> does not have to correspond to the boot CPU.
>
> Introduce a new variable to know if a MADT entry matching the boot CPU
> is found. Furthermore, it's not necessary to check if the MPIDR
>>> On 11.04.16 at 19:46, wrote:
> To simply change the permissions on existing Xen mappings. The existing
> destroy_xen_mappings() is altered to support a change the PTE permissions.
>
> A new destroy_xen_mappings() is introduced, as the special case of not passing
> _PAGE_PRESENT to modify_xen
>>> On 11.04.16 at 19:13, wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
> [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
> XENVER_ but sane."):
>> On 11.04.16 at 18:25, wrote:
>> > But any improvement from an old API to a new one neces
To simply change the permissions on existing Xen mappings. The existing
destroy_xen_mappings() is altered to support a change the PTE permissions.
A new destroy_xen_mappings() is introduced, as the special case of not passing
_PAGE_PRESENT to modify_xen_mappings().
As cleanup (and an ideal funct
flight 90849 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/90849/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
>>> On 11.04.16 at 19:13, wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
> [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
> XENVER_ but sane."):
>> On 11.04.16 at 18:25, wrote:
>> > But any improvement from an old API to a new one neces
On 11/04/16 18:18, Jan Beulich wrote:
On 11.04.16 at 16:04, wrote:
>> @@ -5964,6 +5976,10 @@ void destroy_xen_mappings(unsigned long s, unsigned
>> long e)
>> unsigned int i;
>> unsigned long v = s;
>>
>> +/* Set of valid PTE bits which may be altered. */
>> +#define FLAGS_M
>>> On 11.04.16 at 19:08, wrote:
> If the system admin continously tried to unload and load the patchset
> then we certainly would spam.
>
> But the 'loading' is (or ought to) be a single event. The applying
> or reverting may be done more often.
>
> As such I would say that the operations that
Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
[Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
XENVER_ but sane."):
> On 11.04.16 at 18:25, wrote:
> > But any improvement from an old API to a new one necessarily involves
> > providing a dual facil
>>> On 11.04.16 at 16:04, wrote:
> @@ -5964,6 +5976,10 @@ void destroy_xen_mappings(unsigned long s, unsigned
> long e)
> unsigned int i;
> unsigned long v = s;
>
> +/* Set of valid PTE bits which may be altered. */
> +#define FLAGS_MASK (_PAGE_NX|_PAGE_RW|_PAGE_PRESENT)
> +n
On Mon, Apr 11, 2016 at 06:59:23PM +0200, Dario Faggioli wrote:
> On Mon, 2016-04-11 at 17:38 +0100, George Dunlap wrote:
> > On 11/04/16 17:27, Dario Faggioli wrote:
> > >
> > > Commit 94734ab7c3f5 ("xen: sched: close potential races
> > > when switching scheduler to CPUs") buggily replaced a cal
On Mon, Apr 11, 2016 at 10:55:38AM -0600, Jan Beulich wrote:
> >>> On 11.04.16 at 18:34, wrote:
> > On Mon, Apr 11, 2016 at 12:03:49PM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Mon, Apr 11, 2016 at 09:53:06AM -0600, Jan Beulich wrote:
> >> > >>> On 09.04.16 at 02:37, wrote:
> >> > > On Fri, Apr
>>> On 11.04.16 at 18:53, wrote:
> On Mon, Apr 11, 2016 at 05:25:04PM +0100, Ian Jackson wrote:
>> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
>> Certainly if
>> we are going to permit these strings etc. to be bigger than fits in
>> the old hypercall, the old hypercall ne
On Mon, 2016-04-11 at 17:38 +0100, George Dunlap wrote:
> On 11/04/16 17:27, Dario Faggioli wrote:
> >
> > Commit 94734ab7c3f5 ("xen: sched: close potential races
> > when switching scheduler to CPUs") buggily replaced a call
> > to pcpu_schedule_lock_irq() with just pcpu_schedule_lock(),
> > caus
>>> On 11.04.16 at 18:25, wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
> [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
> XENVER_ but sane."):
>> On 11.04.16 at 16:22, wrote:
>> > But to an extent some of this conversation seems to be
>>> On 11.04.16 at 18:34, wrote:
> On Mon, Apr 11, 2016 at 12:03:49PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Mon, Apr 11, 2016 at 09:53:06AM -0600, Jan Beulich wrote:
>> > >>> On 09.04.16 at 02:37, wrote:
>> > > On Fri, Apr 08, 2016 at 04:50:10PM -0600, Jan Beulich wrote:
>> > >> >>> On 09.04.
On Mon, Apr 11, 2016 at 05:25:04PM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
> [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
> XENVER_ but sane."):
> > On 11.04.16 at 16:22, wrote:
> > > But to an extent some of
Wei Liu writes ("[PATCH OSSTEST] ts-libvirt-build: disable qemu, vmware and
openvz drivers"):
> We don't care about those drivers but they are enabled by default.
>
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
And I will push this shortly.
Thanks,
Ian.
On 11/04/16 17:27, Dario Faggioli wrote:
> Commit 94734ab7c3f5 ("xen: sched: close potential races
> when switching scheduler to CPUs") buggily replaced a call
> to pcpu_schedule_lock_irq() with just pcpu_schedule_lock(),
> causing the relevant irq_safe vs. non-irq_safe ASSERT()
> in check_lock() t
We are going to want to test this elsewhere, too.
No functional change.
Signed-off-by: Ian Jackson
---
sg-run-job |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/sg-run-job b/sg-run-job
index 3e0f966..d1bd124 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -75,7 +75,7 @
Previously this was `broken' (ie, infrastructure failure), which is
not really true - the usual reason is that the L0 has crashed, so that
efforts to manipulate the L1 do not succeed.
Tested using OSSTEST_SIMULATE and this:
diff --git a/sg-run-job b/sg-run-job
index 8b2d5e1..0f8e278 100755
The setting of the suite to "sid" in the snapshot case now occurs in
the case at the top of the script.
This means that gsuite always contains the actual suite name, and the
special cases which set it to sid can be removed.
No functional change.
Signed-off-by: Ian Jackson
---
make-distros-flig
debian_suite is always set in "case $branch in" at the top of
make-distros-flight.
Remove it as part of rationalising the suite variables in this area.
No functional change.
Signed-off-by: Ian Jackson
---
make-distros-flight |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
dif
I hope this series will fix the Cambridge osstest instance's failure
to build anything in its distros-debian-* tests. I'm going to push it
shortly.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
This patch only allows introspection-related MSR write events to
be sent out, improving performance. Should additional events be
required, they can then simply be added to the list of
vmx_introspection_force_enabled_msrs[].
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/hvm/hvm.c | 14 +
flight 90970 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/90970/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfail like 90828
Tests which did not suc
This eliminates two places where $debian_suite is expected to contain
"snapshot" rather than a suite.
We want to change debian_suite to always contain a real suite, so that
we can fold its uses in to other suite variables.
No functional change for existing branches.
Signed-off-by: Ian Jackson
-
Specifically, do not set all_host_di_version to the shell variable
$di_version unless the latter has a nonempty value. A set but empty
value for all_host_di_version does not default to the version for the
specific suite. So this produces install failures.
This bug seems to have been introduced f
Abolish the shell variables $gsuite and $debian_suite (which were
referred to only in make-distros-flight) and set and use the variables
guest_suite and defguestsuite.
These variables are used by the machinery in mfi-common to populate
the runvars.
No functional change (as seen in standalone-gene
The regex in mg-list-all-branches assumes that the BRANCHES= will
either be a singleton entry separated from the following command by a
hard tab or a single quoted list of space separated entries, however
the xen-unstable-coverity line is singleton separated from the command
by a single space.
We
On Mon, Apr 11, 2016 at 12:03:49PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 11, 2016 at 09:53:06AM -0600, Jan Beulich wrote:
> > >>> On 09.04.16 at 02:37, wrote:
> > > On Fri, Apr 08, 2016 at 04:50:10PM -0600, Jan Beulich wrote:
> > >> >>> On 09.04.16 at 00:45, wrote:
> > >> > On Fri, Ap
>>> On 11.04.16 at 05:27, wrote:
> On April 11, 2016 11:10am, wrote:
>> On March 29, 2016 3:37pm, Jan Beulich wrote:
>> > >>> On 25.03.16 at 10:27, wrote:
>> > > On March 18, 2016 6:20pm, wrote:
>> > >> >>> On 17.03.16 at 07:54, wrote:
>> > >> > --- a/xen/drivers/passthrough/iommu.c
>> > >> >
On Mon, Sep 22, 2014 at 1:59 PM, Olaf Hering wrote:
> Use XEN_LOCK_DIR because it is a compiletime setting.
>
> Signed-off-by: Olaf Hering
> Acked-by: Ian Campbell
> ---
> tools/hotplug/Linux/xendomains | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/tools/hotplug
Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
[Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
XENVER_ but sane."):
> On 11.04.16 at 16:22, wrote:
> > But to an extent some of this conversation seems to be on matters of
> > taste.
>
> Agreed.
>
>>> On 11.04.16 at 13:14, wrote:
> On 4/9/2016 6:28 AM, Jan Beulich wrote:
> On 31.03.16 at 12:53, wrote:
>>> @@ -168,13 +226,72 @@ static int hvmemul_do_io(
>>> break;
>>> case X86EMUL_UNHANDLEABLE:
>>> {
>>> -struct hvm_ioreq_server *s =
>>> -hvm_se
Commit 94734ab7c3f5 ("xen: sched: close potential races
when switching scheduler to CPUs") buggily replaced a call
to pcpu_schedule_lock_irq() with just pcpu_schedule_lock(),
causing the relevant irq_safe vs. non-irq_safe ASSERT()
in check_lock() to trigger.
Fix that.
Signed-off-by: Dario Faggiol
>>> On 11.04.16 at 14:20, wrote:
> On 11/04/16 12:14, Yu, Zhang wrote:
>>
>>
>> On 4/8/2016 9:33 PM, Andrew Cooper wrote:
>>> On 31/03/16 11:53, Yu Zhang wrote:
A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
let one ioreq server claim/disclaim its responsibility for the
>>
>>> On 10.04.16 at 16:28, wrote:
> On April 05, 2016 5:48pm, Jan Beulich wrote:
>> >>> On 01.04.16 at 16:47, wrote:
>> > +{
>> > +ASSERT(pdev->domain);
>> > +list_del(&pdev->domain_list);
>> > +pdev->domain = NULL;
>> > +pci_hide_existing_d
>>> On 11.04.16 at 17:50, wrote:
> On Mon, Apr 11, 2016 at 09:44:55AM -0600, Jan Beulich wrote:
>> >>> On 10.04.16 at 21:47, wrote:
>> > That allows the size and offsets to be the same. I checked under ARM32
>> > builds:
>> >
>> >
>> > struct xsplice_patch_func_internal {
>> > const char *
On Mon, Apr 11, 2016 at 09:53:06AM -0600, Jan Beulich wrote:
> >>> On 09.04.16 at 02:37, wrote:
> > On Fri, Apr 08, 2016 at 04:50:10PM -0600, Jan Beulich wrote:
> >> >>> On 09.04.16 at 00:45, wrote:
> >> > On Fri, Apr 08, 2016 at 03:18:09PM -0600, Jan Beulich wrote:
> >> >> >>> On 08.04.16 at 23:
>>> On 09.04.16 at 02:37, wrote:
> On Fri, Apr 08, 2016 at 04:50:10PM -0600, Jan Beulich wrote:
>> >>> On 09.04.16 at 00:45, wrote:
>> > On Fri, Apr 08, 2016 at 03:18:09PM -0600, Jan Beulich wrote:
>> >> >>> On 08.04.16 at 23:10, wrote:
>> >> >> > +int arch_xsplice_perform_rela(struct xsplice_el
On Mon, Apr 11, 2016 at 09:44:55AM -0600, Jan Beulich wrote:
> >>> On 10.04.16 at 21:47, wrote:
> > That allows the size and offsets to be the same. I checked under ARM32
> > builds:
> >
> >
> > struct xsplice_patch_func_internal {
> > const char * name; /*
On Mon, Apr 11, 2016 at 10:32:20AM -0400, Konrad Rzeszutek Wilk wrote:
> > *Hypervisor Maintainers*
> >
> > Jan, the hypervisor patches #2, #5-#17, #21-#23 need your Ack.
>
> s/Ack./Ack please./
> > *Are there any TODOs left from v5 or v6 reviews?*
> >
> > One I hope can be deferred - that is xens
>>> On 11.04.16 at 16:22, wrote:
> Konrad Rzeszutek Wilk writes ("Re: REST MAINTAINERS feedback requested
> Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall
> mirroring XENVER_ but sane."):
>> On Mon, Apr 11, 2016 at 11:50:25AM +0100, Ian Jackson wrote:
>> > I don't think
On 11/04/16 15:04, Andrew Cooper wrote:
> To simply change the permissions on existing Xen mappings. The existing
> destroy_xen_mappings() is altered to support a change the PTE permissions.
>
> A new destroy_xen_mappings() is introduced, as the special case of not passing
> _PAGE_PRESENT to modi
>>> On 10.04.16 at 04:45, wrote:
> On Sat, Apr 09, 2016 at 10:36:00PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Thu, Apr 07, 2016 at 09:43:38AM -0600, Jan Beulich wrote:
>> > >>> On 07.04.16 at 05:09, wrote:
>> > >> > +uint8_t *old_ptr;
>> > >> > +
>> > >> > +BUILD_BUG_ON(PATCH_INSN_SIZE
>>> On 10.04.16 at 21:47, wrote:
> That allows the size and offsets to be the same. I checked under ARM32
> builds:
>
>
> struct xsplice_patch_func_internal {
> const char * name; /* 0 4 */
> uint32_t _pad0;/* 4
>>> On 09.04.16 at 16:42, wrote:
> On Thu, Apr 07, 2016 at 09:38:53AM -0600, Jan Beulich wrote:
>> >>> On 07.04.16 at 05:05, wrote:
>> >> >> > +/* All CPUs are waiting, now signal to disable IRQs. */
>> >> >> > +xsplice_work.ready = 1;
>> >> >> > +smp_wmb();
>> >> >> > +
>
flight 90846 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/90846/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs.
86513
build-armhf
Hi,
I was investigating the behaviour of the -s option and I'm not sure if the
behaviour of xs_open() is exactly as
intended. In my case I am running xenstored in the dom0. Running a strace on
xenstore-read with/without the -s
option shows the tool always using xenstore socket. The flag whi
> *Hypervisor Maintainers*
>
> Jan, the hypervisor patches #2, #5-#17, #21-#23 need your Ack.
s/Ack./Ack please./
> *Are there any TODOs left from v5 or v6 reviews?*
>
> One I hope can be deferred - that is xensyms_read which we use in
> "[PATCH v7 12/24] xsplice,symbols: Implement symbol name re
> * A filesystem in Guest that is integrity-aware can prepare I/Os with
> metadata attached.
> * Filesystems in Guest are capable of transferring metadata from user space.
> Those metadata get lost if we don't pass them through in blkfront.
>
> You may have a look at:
> [1] http://lwn.net/Article
On Mon, Apr 04, 2016 at 02:48:45PM -0400, Benjamin Sanda wrote:
> Moved get_cycles() to time.c and modified to return the core timestamp
> tick count for use by the trace buffer timestamping routines in
> xentrace. get_cycles() was moved to the C file to avoid including the
> register specific head
We don't care about those drivers but they are enabled by default.
Signed-off-by: Wei Liu
---
ts-libvirt-build | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts-libvirt-build b/ts-libvirt-build
index f764b53..2a531b9 100755
--- a/ts-libvirt-build
+++ b/ts-libvirt-build
@@ -62,6 +62,7 @@ sub
On Fri, Apr 08, 2016 at 04:13:56PM +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[Xen-devel] [PATCH v3 00/11] Fixes and improvement
> (including hard affinity!) for Credit2"):
> > Now it's only these two patches that need being Acked:
> >
> > 04/11 xen: sched: close potential races when s
On Fri, Apr 08, 2016 at 03:11:23PM +0200, Dario Faggioli wrote:
> On Fri, 2016-04-08 at 14:00 +0100, George Dunlap wrote:
> > On 08/04/16 13:52, George Dunlap wrote:
> > > On 08/04/16 02:23, Dario Faggioli wrote:
> > > > Signed-off-by: Dario Faggioli
> > > Thanks!
> > >
> > > Reviewed-by: George
On Sat, 2016-04-09 at 04:04 +0200, Luis R. Rodriguez wrote:
> On Thu, Mar 17, 2016 at 03:56:47PM -0600, Toshi Kani wrote:
> >
> > On Wed, 2016-03-16 at 00:29 +0100, Luis R. Rodriguez wrote:
> > >
> > > On x86 Linux code we now have ioremap_uc() that can't use MTRR behind
> > > the scenes, why wou
Konrad Rzeszutek Wilk writes ("Re: REST MAINTAINERS feedback requested Was:Re:
[Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
XENVER_ but sane."):
> On Mon, Apr 11, 2016 at 11:50:25AM +0100, Ian Jackson wrote:
> > I don't think I would be content with simply adding a n
On Fri, Apr 08, 2016 at 08:52:08AM +, Wu, Bob wrote:
>
> Sorry bother, I read the XEN source code recently, and found the XEN platform
> PCI code under drivers/xen/platform-pci.c,
> and I can't fully under this driver's affect, can anybody explain a little
> for me?
>
> Is the platform PCI
On Mon, Apr 11, 2016 at 10:08:58AM -0400, Boris Ostrovsky wrote:
> On 04/11/2016 05:03 AM, Andrew Cooper wrote:
> >c/s f71ecb6 "x86: introduce a new VMASSIST for architectural behaviour of
> >iopl" shifted the vcpu iopl field by 12, but didn't update the logic which
> >reconstructs the guests eflag
On Mon, Apr 11, 2016 at 02:33:37PM +0100, Julien Grall wrote:
> It's helpful to spot any error without having to modify the hypervisor
> code.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Stefano Stabellini
> Reviewed-by: Shannon Zhao
Applied.
___
On Mon, Apr 11, 2016 at 02:33:35PM +0100, Julien Grall wrote:
> The variable enabled_cpus is used to know the number of CPU enabled in
> the MADT.
>
> Currently this variable is used to check the validity of the boot CPU.
> It will be considered invalid when "enabled_cpus > 1".
>
> However, this
On Mon, Apr 11, 2016 at 02:33:34PM +0100, Julien Grall wrote:
> Since the ACPI 6.0 errata document [1], the first entry in the MADT
> does not have to correspond to the boot CPU.
>
> Introduce a new variable to know if a MADT entry matching the boot CPU
> is found. Furthermore, it's not necessary
On Mon, Apr 11, 2016 at 02:33:36PM +0100, Julien Grall wrote:
> This part of the code will never be executed when the entry
> corresponds to the boot CPU.
>
> Also print an error message rather when arch_cpu_init has failed.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Stefano Stabellini
> Re
On 04/11/2016 05:03 AM, Andrew Cooper wrote:
c/s f71ecb6 "x86: introduce a new VMASSIST for architectural behaviour of
iopl" shifted the vcpu iopl field by 12, but didn't update the logic which
reconstructs the guests eflags for migration.
Existing guest kernels set a vIOPL of 1, to prevent them
On Mon, Apr 11, 2016 at 02:33:33PM +0100, Julien Grall wrote:
> The SPCR does not specify if the interrupt is edge or level triggered.
> So the configuration needs to be hardcoded in the code.
>
> Based on the PL011 TRM (see 2.2.8 in ARM DDI 0183G), the interrupt generated
> will be active high. W
To simply change the permissions on existing Xen mappings. The existing
destroy_xen_mappings() is altered to support a change the PTE permissions.
A new destroy_xen_mappings() is introduced, as the special case of not passing
_PAGE_PRESENT to modify_xen_mappings().
As cleanup (and an ideal funct
On Mon, Apr 11, 2016 at 02:33:32PM +0100, Julien Grall wrote:
> Hello,
>
> This patch series fixes secondary CPUs bring up and the use of the PL011 UART
> driver when Xen boots using ACPI.
>
> For all the changes see in each patch.
>
> Regards,
>
> Cc: wei.l...@citrix.com
>
> Julien Grall (5):
On Mon, Apr 11, 2016 at 11:50:25AM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
> [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
> XENVER_ but sane."):
> > On 08.04.16 at 19:41, wrote:
> > > The interface for the old
On 04/08/2016 07:40 PM, Luis R. Rodriguez wrote:
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 1ae89a2721d6..8bb8c1a4615a 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -142,6 +142,15 @@ struct x86_cpuinit_ops {
struct
On Mon, Apr 11, 2016 at 03:04:09PM +0200, Juergen Gross wrote:
> Document the interface between qemu and libxl regarding backends
> supported by qemu.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> v2: - replace variable Xenstore path parts () with bash-like syntax
On 11/04/16 14:31, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 11, 2016 at 01:17:38PM +0100, Andrew Cooper wrote:
>> On 10/04/16 22:14, Konrad Rzeszutek Wilk wrote:
>>> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
>>> index d210bb7..e8cd757 100644
>>> --- a/xen/arch/x86/Makefile
>>> ++
It's helpful to spot any error without having to modify the hypervisor
code.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
Reviewed-by: Shannon Zhao
---
Changes in v2:
- Add Stefano's and Shannon's reviewed-by
---
xen/arch/arm/acpi/boot.c | 7 +++
1 file changed,
Since the ACPI 6.0 errata document [1], the first entry in the MADT
does not have to correspond to the boot CPU.
Introduce a new variable to know if a MADT entry matching the boot CPU
is found. Furthermore, it's not necessary to check if the MPIDR is
duplicated for the boot CPU. So the rest of the
Hello,
This patch series fixes secondary CPUs bring up and the use of the PL011 UART
driver when Xen boots using ACPI.
For all the changes see in each patch.
Regards,
Cc: wei.l...@citrix.com
Julien Grall (5):
drivers/pl011: ACPI: The interrupt should always be high level
triggered
xen/
1 - 100 of 147 matches
Mail list logo
