flight 85979 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85979/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR. vs. 83004
build-armhf-pvops
flight 85985 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85985/
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
This run is configured for baseline tests only.
flight 44243 linux-3.10 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44243/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 19 guest-start/debia
flight 85975 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85975/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
build-amd6
I'm focusing on the style and the logic in the replenish handler:
> /*
> @@ -160,6 +180,7 @@ struct rt_private {
> */
> struct rt_vcpu {
> struct list_head q_elem;/* on the runq/depletedq list */
> +struct list_head replq_elem;/* on the repl event list */
missing space before /*
flight 85972 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85972/
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
flight 85976 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85976/
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
This run is configured for baseline tests only.
flight 44242 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44242/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 14
On Fri, Mar 11, 2016 at 03:08:30PM -0700, Jim Fehlig wrote:
> I recently changed SUSE's Xen package to use the distro qemu instead of
> building
> qemu-xen. This got some other eyes looking at Xen's use of qemu and it was
> noticed that libxl and xen-qemu-dom0-disk-backend.service do not include
>
> +extern int colo_proxy_setup(libxl__colo_proxy_state *cps);
> +extern void colo_proxy_teardown(libxl__colo_proxy_state *cps);
> #endif
> diff --git a/tools/libxl/libxl_colo_proxy.c b/tools/libxl/libxl_colo_proxy.c
> new file mode 100644
> index 000..e07e640
> --- /dev/null
> +++ b/tools/libx
I recently changed SUSE's Xen package to use the distro qemu instead of building
qemu-xen. This got some other eyes looking at Xen's use of qemu and it was
noticed that libxl and xen-qemu-dom0-disk-backend.service do not include
'-no-user-config' when invoking qemu. The latter also does not include
flight 85950 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85950/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 85254
build-i386-rumpuserxen6
On Fri, Mar 11, 2016 at 2:07 PM, Konrad Rzeszutek Wilk <
konrad.w...@oracle.com> wrote:
> On Mon, Mar 07, 2016 at 04:46:39PM -0500, Paul Mogren wrote:
> > Hey all,
> >
> > I'm trying to get a storage domain up and running in Xen 4.4. I'm
> currently
> > using Ubuntu 14.04 for the dom0, storage dom
Sorry I send this mail by mistake. Please ignore it. I send another one with
correct commit message.
On 03/11/2016 03:13 PM, Zhigang Wang wrote:
> Oracle-Bug: 22879856
>
> Signed-off-by: Zhigang Wang
> ---
> tools/xenstat/libxenstat/src/xenstat_linux.c | 8 ++--
> 1 file changed, 6 inserti
xentop will segmentation fault in this case:
# ip link set eth1 down
# ip link set eth1 name ETH
# xentop
This patch will let xentop to handle all uppercase network interface name.
Signed-off-by: Zhigang Wang
---
tools/xenstat/libxenstat/src/xenstat_linux.c | 8 ++--
1 file changed,
Oracle-Bug: 22879856
Signed-off-by: Zhigang Wang
---
tools/xenstat/libxenstat/src/xenstat_linux.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/xenstat/libxenstat/src/xenstat_linux.c
b/tools/xenstat/libxenstat/src/xenstat_linux.c
index 931b24e..d33eca1 100644
flight 85924 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85924/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 85850 pass in 85924
test-armhf-armhf-xl-credit2 15 gu
Budget replenishment and enforcement are separated by adding
a replenishment timer, which fires at the next most imminent
release time of all runnable vcpus.
A replenishment queue has been added to keep track of all vcpus that
are runnable.
The following functions have major changes to manage the
On Mon, Mar 07, 2016 at 04:46:39PM -0500, Paul Mogren wrote:
> Hey all,
>
> I'm trying to get a storage domain up and running in Xen 4.4. I'm currently
> using Ubuntu 14.04 for the dom0, storage domain and guest. I'm currently
> following the steps here,
> http://wiki.xenproject.org/wiki/Storage_d
This adds paravirt hooks for unsafe MSR access. On native, they
call native_{read,write}_msr. On Xen, they use
xen_{read,write}_msr_safe.
Nothing uses them yet for ease of bisection. The next patch will
use them in rdmsrl, wrmsrl, etc.
I intentionally didn't make them OOPS on #GP on Xen. I th
This demotes an OOPS and likely panic due to a failed non-"safe" MSR
access to a WARN and, for RDMSR, a return value of zero. If
panic_on_oops is set, then failed unsafe MSR accesses will still
oops and panic.
To be clear, this type of failure should *not* happen. This patch
exists to minimize t
These hooks match the _safe variants, so name them accordingly.
This will make room for unsafe PV hooks.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/paravirt.h | 33 +
arch/x86/include/asm/paravirt_types.h | 8
arch/x86/kernel/paravirt.
Enabling CONFIG_PARAVIRT had an unintended side effect: rdmsr turned
into rdmsr_safe and wrmsr turned into wrmsr_safe, even on bare
metal. Undo that by using the new unsafe paravirt MSR hooks.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/paravirt.h | 9 +++--
1 file changed, 3 in
This will cause unchecked native_rdmsr_safe failures to return
deterministic results.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/msr.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 13da359881d7..
Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently
turns all rdmsr and wrmsr operations into the safe variants without
any checks that the operations actually succeed.
With CONFIG_PARAVIRT=n, unchecked MSR failures OOPS and probably
cause boot to fail if they happen before init s
On Fri, Mar 11, 2016 at 09:35:19AM -0500, Konrad Rzeszutek Wilk wrote:
> > >> Nor would
> > >> that deal with avoiding reserved regions not too far above 1Mb,
> > >> since at best the main payload can be relocatable (but certainly
> > >> not the binary seen by the boot loader, as at least multiboo
On Fri, Mar 11, 2016 at 06:33:15PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Friday, March 11, 2016, Daniel Kiper wrote:
>
> > On Fri, Mar 11, 2016 at 04:44:00PM +0100, Vladimir 'phcoder' Serbinenko
> > wrote:
> >
> > [...]
> >
> > > multiboot2 spec is a rolling update.
> >
> > OK. So, I th
On 11/03/16 17:34, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1093,6 +1093,22 @@ static bool_t vcpu_has(
> #define vcpu_must_have_cx16() vcpu_must_have(0x0001, ECX, 13)
> #define vcpu_m
The former in an attempt to at least gradually support all simple data
movement instructions. The latter just because it shares the opcode
with the former.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -78,7 +7
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1093,6 +1093,22 @@ static bool_t vcpu_has(
#define vcpu_must_have_cx16() vcpu_must_have(0x0001, ECX, 13)
#define vcpu_must_have_avx() vcpu_must_have(0x0001, ECX, 28)
The latter are their canonical names, used already in the instruction
emulator.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -205,12 +205,12 @@ static void __init early_cpu_detect(void
c->x86_model += ((
On Friday, March 11, 2016, Daniel Kiper wrote:
> On Fri, Mar 11, 2016 at 04:44:00PM +0100, Vladimir 'phcoder' Serbinenko
> wrote:
>
> [...]
>
> > multiboot2 spec is a rolling update.
>
> OK. So, I think that we should do this in that way:
> - apply this patch series after polishing;
> I hop
1: x86: rename XMM* features to SSE*
2: x86emul: check host features alongside guest ones where needed
3: x86emul: support MOVBE and CRC32
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, Mar 11, 2016 at 10:55 AM, Dario Faggioli
wrote:
> On Fri, 2016-03-11 at 09:49 -0500, Meng Xu wrote:
>> > Yes.
>> > Consistency may be helpful to avoid some easy-to-avoid lock errors.
>> > Moreover, without my fix, I think it would not lead dead lock, as
>> > the pcidevs_lock is not being t
Add back xen-devel
On Fri, Mar 11, 2016 at 05:23:22PM +0100, Safa Hamza wrote:
> ok .. can u tell me how compile xen with debug symbols !! i have xen-syms
> after compiling xen with "make dist-xen XEN_TARGET_ARCH=arm32
> CROSS_COMPILE=arm-linux-gnueabihf- CONFIG_EARLY_PRINTK=omap5432" is this
>
Hi Doug,
Can you tell me what steps I should follow for this project?
Regards,
Sabiya
On Mar 5, 2016 11:59 PM, "sabiya kazi" wrote:
>
> Hi Doug,
>
> I would like to work on the project *Rust Bindings for libxl *as a part
> of Outreachy Program 2016.
>
> I have completed my B.E in Computer enginee
On Thu, Oct 1, 2015 at 12:15 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> > These could still be open coded in an inlined fashion, like the scheduler
>> > usage.
>>
>> We could have a raw_rdmsr for those.
>>
>> OTOH, I'm still not 100% convinced that this warn-but-don't-die behavior
On Fri, Mar 11, 2016 at 04:42:27PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Friday, March 11, 2016, Daniel Kiper wrote:
>
> > On Thu, Mar 10, 2016 at 09:23:23PM +0100, Vladimir 'phcoder' Serbinenko
> > wrote:
> > > On Wednesday, March 2, 2016, Daniel Kiper > > wrote:
> > >
> > > > Add gru
Commit a929bee0e652 ("x86/vmx: Fix injection of #DB traps following
XSA-156") prevents an infinite loop in certain #DB traps. However, it
changed the behavior to not call hvm_hw_inject_trap() for #DB and #AC
traps which which means that the debug registers are not restored
correctly and nullified c
On Fri, Mar 11, 2016 at 04:44:00PM +0100, Vladimir 'phcoder' Serbinenko wrote:
[...]
> multiboot2 spec is a rolling update.
OK. So, I think that we should do this in that way:
- apply this patch series after polishing;
I hope that it will happen next week,
- update multiboot2 doc,
- ad
On Thu, Mar 10, 2016 at 09:44:31PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper wrote:
>
> > Currently multiboot2 protocol loads image exactly at address specified in
> > ELF or multiboot2 header. This solution works quite well on legacy BIOS
> > platform
On Fri, Mar 11, 2016 at 01:39:04PM +0800, Wen Congyang wrote:
> Signed-off-by: Wen Congyang
> ---
> tools/libxl/libxl.c | 4 ++--
> tools/libxl/libxl.h | 8
> tools/libxl/libxl_create.c | 4 ++--
> tools/libxl/libxl_dom_save.c | 6 +++---
> tools/l
>
>
> > > + if (relocatable)
> > > +{
> > > + if (base_addr > min_addr)
> > > + grub_multiboot_payload_eip += base_addr - min_addr;
> > > + else
> > > + grub_multiboot_payload_eip -= min_addr - base_addr;
> > > +}
> > > +
> > >
> > Why is it relative to min_addr? Soun
On Fri, 2016-03-11 at 09:41 -0500, Meng Xu wrote:
> Thank you very much for your explanation and education! They are
> really helpful! :-D
>
> Let me summarize: ;-)
> >
> > | spin_lock |
> spin_lock_irq | spin_lock_irqsave
> >
> > Can run in i
On Fri, Mar 11, 2016 at 11:02:26AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 11, 2016 at 04:47:47PM +0100, Safa Hamza wrote:
> > now i did just like u said ... a new error appears
>
> Adding XEn-devel back. Please reply all.
>
> > *
i did just like u said ... a new error appears
**
U-Boot# fdt addr $dtb_addr_r
U-Boot# fdt resize
U-Boot# fdt set /chosen xen,xen-bootargs \"$xen_bootargs\"
U-Boot# fdt resize
U-Boot# fdt set /chosen xen,dom0-bootargs \"$d
On Thu, Mar 10, 2016 at 09:41:26PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper wrote:
>
> > Currently multiboot2 protocol loads image exactly at address specified in
> > ELF or multiboot2 header. This solution works quite well on legacy BIOS
> > platform
On Fri, Mar 11, 2016 at 04:47:47PM +0100, Safa Hamza wrote:
> now i did just like u said ... a new error appears
Adding XEn-devel back. Please reply all.
> **
> U-Boot# fdt addr $dtb_addr_r
> U-Boot# fdt resize
> U-Boot#
In that case (with the new value being held in, or now in one case cast
to, a 32-bit variable) there's no need to go through the long mode part
of the checks.
Primarily this was meant to hopefully address Coverity ID 1355278, but
since the change produces smaller code as well I think we should use
On 03/11/2016 10:43 AM, Jan Beulich wrote:
On 11.03.16 at 16:39, wrote:
On 03/11/2016 04:07 AM, Jan Beulich wrote:
On 10.03.16 at 19:30, wrote:
This change will cause the boot to fail if you do not specify an XSM
policy during boot; if you need to load a policy from dom0, use the
"flask=late
On Fri, 2016-03-11 at 09:49 -0500, Meng Xu wrote:
> > Yes.
> > Consistency may be helpful to avoid some easy-to-avoid lock errors.
> > Moreover, without my fix, I think it would not lead dead lock, as
> > the pcidevs_lock is not being taken
> > In IRQ context. Right?
> I think without your fix, the
On Friday, March 11, 2016, Daniel Kiper wrote:
> On Thu, Mar 10, 2016 at 09:23:23PM +0100, Vladimir 'phcoder' Serbinenko
> wrote:
> > On Wednesday, March 2, 2016, Daniel Kiper > wrote:
> >
> > > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit
> platforms
> > > when multiboot2 c
On Friday, March 11, 2016, Daniel Kiper wrote:
> On Fri, Mar 11, 2016 at 01:27:32PM +0100, Vladimir 'phcoder' Serbinenko
> wrote:
> > On Wednesday, March 9, 2016, Daniel Kiper > wrote:
> >
> > > On Wed, Mar 02, 2016 at 05:51:36PM +0100, Daniel Kiper wrote:
> > > > Hi,
> > > >
> > > > This patch
>>> On 11.03.16 at 16:39, wrote:
> On 03/11/2016 04:07 AM, Jan Beulich wrote:
> On 10.03.16 at 19:30, wrote:
>>> This change will cause the boot to fail if you do not specify an XSM
>>> policy during boot; if you need to load a policy from dom0, use the
>>> "flask=late" boot parameter.
>>
>>
>>> On 11.03.16 at 15:51, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3091,24 +3091,23 @@ static int vmx_handle_eoi_write(void)
> * It is the callers responsibility to ensure that this function is only used
> * in the context of an appropriate vmexit.
>
On Friday, March 11, 2016, Daniel Kiper wrote:
> On Thu, Mar 10, 2016 at 09:23:23PM +0100, Vladimir 'phcoder' Serbinenko
> wrote:
> > On Wednesday, March 2, 2016, Daniel Kiper > wrote:
> >
> > > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit
> platforms
> > > when multiboot2 c
flight 85893 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85893/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-multivcpu 3 host-install(3) broken in 85820 pass in 85893
test-armhf-armhf-libvirt-qcow2
On 03/11/2016 04:07 AM, Jan Beulich wrote:
On 10.03.16 at 19:30, wrote:
This change will cause the boot to fail if you do not specify an XSM
policy during boot; if you need to load a policy from dom0, use the
"flask=late" boot parameter.
And what mode is the system in until that happens? From
On Friday, March 11, 2016, Daniel Kiper wrote:
> On Thu, Mar 10, 2016 at 09:26:06PM +0100, Vladimir 'phcoder' Serbinenko
> wrote:
> > On Wednesday, March 2, 2016, Daniel Kiper > wrote:
> >
> > > Add tags used to pass ImageHandle to loaded image if requested.
> > > It is used by at least ExitBoot
This run is configured for baseline tests only.
flight 44241 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44241/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build
On Fri, Mar 11, 2016 at 10:20:01AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 11, 2016 at 04:05:58PM +0100, Safa Hamza wrote:
And please do not drop Xen-devel. Adding it back on.
> > i did like u said but nothing change ..
> >
>
> No you didn't. See below:
> > U-Boot# setenv dom0_bootarg
Rename controller flag to make it clearer what it means.
Add some documentation as well.
Signed-off-by: Michael S. Tsirkin
---
include/hw/pci/msi.h | 2 +-
hw/i386/kvm/apic.c | 2 +-
hw/i386/xen/xen_apic.c | 2 +-
hw/intc/apic.c | 2 +-
hw/intc/a
>
>> In fact, the deadlock arises because IRQs interrupt asynchronously what the
>> CPU is doing, and that can happen when the CPU has taken the lock already.
>> But
>> if the 'asynchronous' part goes away, we really don't care whether a lock is
>> take
>> at time t1 with IRQ enabled, and at time
On Fri, Mar 11, 2016 at 02:07:11AM -0700, Jan Beulich wrote:
> >>> On 10.03.16 at 19:30, wrote:
> > This change will cause the boot to fail if you do not specify an XSM
> > policy during boot; if you need to load a policy from dom0, use the
> > "flask=late" boot parameter.
>
> And what mode is th
Commit a929bee0e652 ("x86/vmx: Fix injection of #DB traps following
XSA-156") prevents an infinite loop in certain #DB traps. However, it
changed the behavior to not call hvm_hw_inject_trap() for #DB and #AC
traps which which means that the debug registers are not restored
correctly and nullified c
On Thu, Mar 10, 2016 at 09:04:22PM +0100, Safa Hamza wrote:
> hello
> i'm trying to run xen on omap5 following
> this
> http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM
>
> the execution stops at this point
>
> **
On Fri, Mar 11, 2016 at 01:39:04PM +0800, Wen Congyang wrote:
> Signed-off-by: Wen Congyang
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 11/03/16 14:13, Jan Beulich wrote:
On 11.03.16 at 14:21, wrote:
>> On 11/03/16 12:06, Jan Beulich wrote:
>> On 11.03.16 at 10:22, wrote:
Sadly, c/s cf393624 "x86: use 2M superpages for text/data/bss mappings"
exposes a bug in all Syslinux variants, including ISOlinux and
>>>
On Fri, Mar 11, 2016 at 01:39:02PM +0800, Wen Congyang wrote:
> xc_domain_save() and xc_domain_restore's parameter will use this type,
> so it should be public.
>
> Signed-off-by: Wen Congyang
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@li
On Fri, Mar 11, 2016 at 01:39:03PM +0800, Wen Congyang wrote:
> checkpointed_stream is also renamed to stream_type
>
> Signed-off-by: Wen Congyang
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hi Quan and Dario,
On Fri, Mar 11, 2016 at 5:35 AM, Dario Faggioli
wrote:
> On Fri, 2016-03-11 at 06:54 +, Xu, Quan wrote:
>> On March 11, 2016 11:25am, wrote:
>> >
>> > On Wed, Mar 9, 2016 at 8:17 AM, Quan Xu wrote:
>> > >
>> > > pcidevs_lock should be held with interrupt enabled. However
> >> Nor would
> >> that deal with avoiding reserved regions not too far above 1Mb,
> >> since at best the main payload can be relocatable (but certainly
> >> not the binary seen by the boot loader, as at least multiboot1
> >> doesn't support anything like that).
> >
> > The only reason Xen sits
>>> On 11.03.16 at 14:21, wrote:
> On 11/03/16 12:06, Jan Beulich wrote:
> On 11.03.16 at 10:22, wrote:
>>> Sadly, c/s cf393624 "x86: use 2M superpages for text/data/bss mappings"
>>> exposes a bug in all Syslinux variants, including ISOlinux and
>>> PXELinux, causing a failure to boot.
>>>
On Fri, 2016-03-11 at 12:36 +, Xu, Quan wrote:
> On March 11, 2016 6:36pm, wrote:
> > On Fri, 2016-03-11 at 06:54 +, Xu, Quan wrote:
> > >
> > So, now, if we know for sure that a lock is _never_ever_ever_ taken
> > from
> > interrupt context, can we mix spin_lock() and spin_lock_irq() on
Hi Wei and Quan,
On Fri, Mar 11, 2016 at 8:14 AM, Xu, Quan wrote:
> On March 10, 2016 11:56pm, Wei Liu wrote:
>> On Thu, Mar 10, 2016 at 10:08:04AM -0500, Meng Xu wrote:
>> > On Thu, Mar 10, 2016 at 9:42 AM, Dario Faggioli
>> > wrote:
>> > > Meng Xu is one of the maintainers of the RT-Xen projec
On Thu, Mar 10, 2016 at 09:28:25PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper wrote:
>
> > Do not pass memory maps to image if it asked for EFI boot services.
> > Main reason for not providing maps is because they will likely be
> > invalid. We do a few
On Thu, Mar 10, 2016 at 09:26:06PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper wrote:
>
> > Add tags used to pass ImageHandle to loaded image if requested.
> > It is used by at least ExitBootServices() function.
> >
> > Signed-off-by: Daniel Kiper >
> >
On 11/03/16 13:13, Jan Beulich wrote:
On 11.03.16 at 13:56, wrote:
>> On 11/03/16 11:29, Jan Beulich wrote:
>> On 10.03.16 at 23:00, wrote:
@@ -771,6 +772,7 @@ void __init setup_frametable_mappings(paddr_t ps,
paddr_t pe)
nr_second = frametable_size >> SECOND_SHIFT;
On Thu, Mar 10, 2016 at 09:23:23PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper wrote:
>
> > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
> > when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS.
> > Relocator
On 11/03/16 12:06, Jan Beulich wrote:
On 11.03.16 at 10:22, wrote:
>> Sadly, c/s cf393624 "x86: use 2M superpages for text/data/bss mappings"
>> exposes a bug in all Syslinux variants, including ISOlinux and
>> PXELinux, causing a failure to boot.
>>
>> Xen currently requires its bootloader
On Fri, Mar 11, 2016 at 01:15:04PM +, One Thousand Gnomes wrote:
> On Fri, 11 Mar 2016 13:25:14 +0100
> Peter Zijlstra wrote:
>
> > On Fri, Mar 11, 2016 at 12:59:28PM +0100, Juergen Gross wrote:
> > > Some hardware (e.g. Dell Studio laptops) require special functions to
> > > be called on phy
On Fri, 11 Mar 2016 13:25:14 +0100
Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 12:59:28PM +0100, Juergen Gross wrote:
> > Some hardware (e.g. Dell Studio laptops) require special functions to
> > be called on physical cpu 0 in order to avoid occasional hangs. When
> > running as dom0 under Xe
On Fri, Mar 11, 2016 at 01:27:32PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 9, 2016, Daniel Kiper wrote:
>
> > On Wed, Mar 02, 2016 at 05:51:36PM +0100, Daniel Kiper wrote:
> > > Hi,
> > >
> > > This patch series:
> > > - enables EFI boot services usage in loaded images
On March 10, 2016 11:56pm, Wei Liu wrote:
> On Thu, Mar 10, 2016 at 10:08:04AM -0500, Meng Xu wrote:
> > On Thu, Mar 10, 2016 at 9:42 AM, Dario Faggioli
> > wrote:
> > > Meng Xu is one of the maintainers of the RT-Xen project, which is
> > > from where the RTDS scheduler comes. He also is the main
>>> On 11.03.16 at 13:56, wrote:
> On 11/03/16 11:29, Jan Beulich wrote:
> On 10.03.16 at 23:00, wrote:
>>> @@ -771,6 +772,7 @@ void __init setup_frametable_mappings(paddr_t ps,
>>> paddr_t pe)
>>> nr_second = frametable_size >> SECOND_SHIFT;
>>> second_base = alloc_boot_pages(nr_s
On 11/03/16 13:57, Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 01:48:12PM +0100, Juergen Gross wrote:
>> On 11/03/16 13:42, Peter Zijlstra wrote:
>>> how about something like:
>>>
>>> struct xen_callback_struct {
>>> struct work_struct work;
>>> struct completion done;
>
On Fri, Mar 11, 2016 at 01:48:12PM +0100, Juergen Gross wrote:
> On 11/03/16 13:42, Peter Zijlstra wrote:
> > how about something like:
> >
> > struct xen_callback_struct {
> > struct work_struct work;
> > struct completion done;
int (*func)(void*);
>
On 11/03/16 11:29, Jan Beulich wrote:
On 10.03.16 at 23:00, wrote:
> First of all - please correctly Cc maintainers (there were two recent
> changes for ARM).
>
>> --- a/xen/arch/arm/mm.c
>> +++ b/xen/arch/arm/mm.c
>> @@ -730,6 +730,7 @@ void __init setup_xenheap_mappings(unsigned long
>> ba
On 11/03/16 13:42, Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 01:19:50PM +0100, Peter Zijlstra wrote:
>> On Fri, Mar 11, 2016 at 12:59:30PM +0100, Juergen Gross wrote:
>>> +int call_sync_on_phys_cpu(unsigned cpu, int (*func)(void *), void *par)
>>> +{
>>> + cpumask_var_t old_mask;
>>> + in
On Fri, Mar 11, 2016 at 01:43:53PM +0100, Juergen Gross wrote:
> On 11/03/16 13:19, Peter Zijlstra wrote:
> > On Fri, Mar 11, 2016 at 12:59:30PM +0100, Juergen Gross wrote:
> >> +int call_sync_on_phys_cpu(unsigned cpu, int (*func)(void *), void *par)
> >> +{
> >> + cpumask_var_t old_mask;
> >> +
On 11/03/16 13:19, Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 12:59:30PM +0100, Juergen Gross wrote:
>> +int call_sync_on_phys_cpu(unsigned cpu, int (*func)(void *), void *par)
>> +{
>> +cpumask_var_t old_mask;
>> +int ret;
>> +
>> +if (cpu >= nr_cpu_ids)
>> +return -EI
On Fri, Mar 11, 2016 at 01:19:50PM +0100, Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 12:59:30PM +0100, Juergen Gross wrote:
> > +int call_sync_on_phys_cpu(unsigned cpu, int (*func)(void *), void *par)
> > +{
> > + cpumask_var_t old_mask;
> > + int ret;
> > +
> > + if (cpu >= nr_cpu_ids)
On March 11, 2016 6:36pm, wrote:
> On Fri, 2016-03-11 at 06:54 +, Xu, Quan wrote:
> > On March 11, 2016 11:25am, wrote:
> > >
> > > On Wed, Mar 9, 2016 at 8:17 AM, Quan Xu wrote:
> > > >
> > > > pcidevs_lock should be held with interrupt enabled. However there
> > > > remains an exception in
On Friday 11 March 2016 13:25:14 Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 12:59:28PM +0100, Juergen Gross wrote:
> > Some hardware (e.g. Dell Studio laptops) require special functions to
> > be called on physical cpu 0 in order to avoid occasional hangs. When
> > running as dom0 under Xen th
On Wednesday, March 9, 2016, Daniel Kiper wrote:
> On Wed, Mar 02, 2016 at 05:51:36PM +0100, Daniel Kiper wrote:
> > Hi,
> >
> > This patch series:
> > - enables EFI boot services usage in loaded images
> > by multiboot2 protocol,
> > - add support for multiboot2 protocol compatible
> >
On Fri, Mar 11, 2016 at 12:59:28PM +0100, Juergen Gross wrote:
> Some hardware (e.g. Dell Studio laptops) require special functions to
> be called on physical cpu 0 in order to avoid occasional hangs. When
> running as dom0 under Xen this could be achieved only via special boot
> parameters (vcpu p
On Fri, Mar 11, 2016 at 12:59:30PM +0100, Juergen Gross wrote:
> +int call_sync_on_phys_cpu(unsigned cpu, int (*func)(void *), void *par)
> +{
> + cpumask_var_t old_mask;
> + int ret;
> +
> + if (cpu >= nr_cpu_ids)
> + return -EINVAL;
> +
> + if (!alloc_cpumask_var(&old_
>>> On 11.03.16 at 10:22, wrote:
> Sadly, c/s cf393624 "x86: use 2M superpages for text/data/bss mappings"
> exposes a bug in all Syslinux variants, including ISOlinux and
> PXELinux, causing a failure to boot.
>
> Xen currently requires its bootloader to decompress it, and place it at
> the 1MB
flight 85888 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85888/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 85031
Regressions whic
Some hardware (e.g. Dell Studio laptops) require special functions to
be called on physical cpu 0 in order to avoid occasional hangs. When
running as dom0 under Xen this could be achieved only via special boot
parameters (vcpu pinning) limiting the hypervisor in it's scheduling
decisions.
This pat
1 - 100 of 123 matches
Mail list logo
