flight 65123 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65123/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail REGR. vs. 60684
test-amd64
On 11/27/2015 01:10 AM, Oleksii Kurochko wrote:
Hello all,
Do you have any ideas about previously mentioned question?
With best regards,
Oleksii
On Tue, Nov 24, 2015 at 6:48 PM, Oleksii Kurochko mailto:oleksii.kuroc...@globallogic.com>> wrote:
Hi all,
I am trying to enable XenGT fo
On Thu, Nov 26, 2015 at 12:49:42AM -0700, Jan Beulich wrote:
> >>> On 26.11.15 at 00:27, wrote:
> > A few more data points: I also tested Xen 4.6 on VMware ESXi 5.5, and
> > it yields similar results. Not surprising, since Fusion uses basically
> > the same virtualization engine.
> >
> > However,
This run is configured for baseline tests only.
flight 38359 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38359/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-xsm5 xen-build
flight 65121 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 64579
test-amd64-i386-xl-
flight 65124 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65124/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340
test-amd64-amd64-libvirt-
flight 65114 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65114/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 65066
test-amd64-amd64-libvirt-vhd
When allocating a pciback device fails, avoid the possibility of a
use after free.
Reported-by: Jonathan Creekmore
Signed-off-by: Doug Goldstein
---
drivers/xen/xen-pciback/xenbus.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers
flight 65138 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65138/
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
This run is configured for baseline tests only.
flight 38358 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38358/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-xsm5 xen-buildfail bl
On 26/11/15 18:49, Andrew Cooper wrote:
> On 26/11/15 16:14, David Vrabel wrote:
>> If more than 1024 event channels are bound to a evtchn device then it
>> possible (even with well behaved applications) for the ring to
>> overflow and events to be lost (reported as an -EFBIG error).
>>
>> Dynamica
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.4-rc2-tag
xen: bug fixes for 4.4-rc2
- - Fix gntdev and numa balancing.
- - Fix x86 boot crash due to unallocated legacy irq descs.
- -
On 26/11/15 16:14, David Vrabel wrote:
> If more than 1024 event channels are bound to a evtchn device then it
> possible (even with well behaved applications) for the ring to
> overflow and events to be lost (reported as an -EFBIG error).
>
> Dynamically increase the size of the ring so there is a
On 20/11/15 16:25, Boris Ostrovsky wrote:
> After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
> allocating descs for legacy IRQs") early_irq_init() will no longer
> preallocate descriptors for legacy interrupts if PIC does not
> exist, which is the case for Xen PV guests.
>
> Ther
El 11/11/15 a les 18.14, Andrew Cooper ha escrit:
> On 06/11/15 16:05, Roger Pau Monne wrote:
>> diff --git a/tools/libxl/libxl_stream_write.c
>> b/tools/libxl/libxl_stream_write.c
>> index 52a60d7..0a6eaf9 100644
>> --- a/tools/libxl/libxl_stream_write.c
>> +++ b/tools/libxl/libxl_stream_write.c
flight 65119 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65119/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 95ac787f02d5c85d046af5cefa3b49f0f8841733
baseline version:
ovmf 9f419739d1ae849e0c4d75a131502f9367c
flight 65135 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65135/
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 Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Copy and modify MADT table before passing it to Dom0. Copy
> dom0_max_vcpus of GICCs and GICD as well.
>
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/domain_build.c | 98
> ++
On 10/11/15 20: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 ar
Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Be more careful with error
handling in libxl__dm_runas_helper()"):
> On Thu, 2015-11-26 at 10:03 +, Ian Campbell wrote:
> > My reference when reviewing this is the (IMHO more canonical) http://pubs.o
> > pengroup.org/onlinepubs/9699919799/fu
On 20/11/15 15:02, Stefano Stabellini wrote:
> Use READ_ONCE through the code, rather than explicit barriers.
Applied to for-linus-4.5, thanks.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Boris Ostrovsky writes ("[PATCH] libxl: Be more careful with error handling in
libxl__dm_runas_helper()"):
> getpwnam_r() has fairly complicated return rules. From man pages:
>
> RETURN VALUE
> ...
> On success, getpwnam_r() and getpwuid_r() return zero, and set
> *result to p
flight 65112 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65112/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-buildfail in 65062 REGR. vs. 63449
test-amd64-amd64-
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Copy and modify FADT table before passing it to Dom0. Set PSCI_COMPLIANT
> and PSCI_USE_HVC.
>
> Signed-off-by: Shannon Zhao
>
> xen/arch/arm/domain_build.c | 45
> +
> 1 f
Hello all,
Do you have any ideas about previously mentioned question?
With best regards,
Oleksii
On Tue, Nov 24, 2015 at 6:48 PM, Oleksii Kurochko <
oleksii.kuroc...@globallogic.com> wrote:
> Hi all,
>
> I am trying to enable XenGT for Android on board vtc1010 in PV mode.
> Used:
> - Intel® At
On Thu, 26 Nov 2015, Stefano Stabellini wrote:
> On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> > From: Shannon Zhao
> >
> > It needs to copy and change the contents of some ACPI and EFI tables for
> > Dom0. Here define a enum for those tables.
> >
> > Signed-off-by: Parth Dixit
> > Sign
If HVM support unavailable, advertising hvm_directio is misleading.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/sysctl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 58cbd70..c440c93 100644
--
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Signed-off-by: Shannon Zhao
It should probably be merged with patch #37.
Please add more details on how the offset is calculated, whether it is
bytes, and why all the tables have been page aligned.
> xen/arch/arm/a
libxlConnectDomainXMLFromNative calls both xenParseXM and xenParseXL
with cfg->verInfo->xen_version_major, however AFAICT they both (either
inherently, or through there use of xenParseConfigCommon expect a
value from xenConfigVersionEnum (which does not correspond to
xen_version_major).
The actual
This new cfg field was addded in 4.0 by 68a94cf528e6 "xm: Add maxvcpus
support" and, more crucially these day, it is what xl supports.
This removes the MAX_VIRT_CPUS limitation for such versions of Xen
(since maxvcpus is simply a count, not a bit mask) which is
particularly crucial on ARM where MA
libvirt currently clamps the maximum number of vcpus to MAX_VIRT_CPUS
== XEN_LEGACY_MAX_VCPUS, which on ARM is 1 (because all guests are expected
to support vcpu info placement).
Even on x86 this limitation is a hold over from an older xm interface where
the maximum number of vcpus was expressed a
El 12/11/15 a les 17.57, Jan Beulich ha escrit:
On 06.11.15 at 17:05, wrote:
>> @@ -1183,6 +1184,301 @@ int arch_set_info_guest(
>> #undef c
>> }
>>
>> +static inline int check_segment(struct segment_register reg,
>
> Passed by value?
Hm, right, will pass by reference in next version.
The name is chosen to be consistent with Linux. Doing this allows
early_intel_workaround() to be removed from common code.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpu/common.c | 17 +++--
xen/arch/x86/cpu/cpu.h| 3 +--
xen/arch/x86/cpu/intel.c | 5 +
Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the
commandline-provided masks would take effect in Xen's view of the features.
As the masks got applied after the query for features, the redundant call to
generic_identify() would clobber the wrong feature information with t
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> It needs to copy and change the contents of some ACPI and EFI tables for
> Dom0. Here define a enum for those tables.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> xen/include/asm-arm/acpi.h |
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Estimate the memory required for loading acpi/efi tables in Dom0. Alloc
> the pages to store the new created EFI and ACPI tables and free these
> pages when destroying domain.
Could you please explain what you are page
On November 26, 2015 2:09:02 AM EST, Bob Liu wrote:
>
>On 11/26/2015 10:57 AM, Konrad Rzeszutek Wilk wrote:
>> On Thu, Nov 26, 2015 at 10:28:10AM +0800, Bob Liu wrote:
>>>
>>> On 11/26/2015 06:12 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Nov 25, 2015 at 03:56:03PM -0500, Konrad Rzeszutek Wilk
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Parth Dixit
>
> ACPI memory is seperate from conventional memory and should be marked
> as reserved while passing to DOM0. Create a new meminfo structure to
> store all the acpi tables listed in uefi.
>
> Signed-off-by: Parth Dixit
> S
If more than 1024 event channels are bound to a evtchn device then it
possible (even with well behaved applications) for the ring to
overflow and events to be lost (reported as an -EFBIG error).
Dynamically increase the size of the ring so there is always enough
space for all bound events. Well b
On Wed, 18 Nov 2015, Julien Grall wrote:
> On 18/11/15 03:01, Shannon Zhao wrote:
> > "All above tables will be mapped to Dom0 non-RAM space. Since when
> > booting through ACPI it doesn't need the grant table region(see below
> > section 3), it could use this region to store the tables or use the
On Tue, 17 Nov 2015, Shannon Zhao wrote:
> On 2015/11/17 19:58, Julien Grall wrote:
> > Hi Shannon,
> >
> > On 17/11/15 09:40, shannon.z...@linaro.org wrote:
> >> From: Shannon Zhao
> >>
> >> EFI table, memory description table and some of acpi tables will be
> >> placed after DOM0 memory space.
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Parth Dixit
>
> Parse ACPI SPCR (Serial Port Console Redirection table) table and
> initialize the serial port pl011.
>
> Signed-off-by: Naresh Bhat
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> xen/drivers/char
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Rename SERHND_DTUART to SERHND_UART in order to reuse it when booting
> with ACPI.
But actually I fail to see where is it being used with ACPI.
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/vuart.c
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Refactor pl011 driver to dt and common initialization parts. This will
> be useful later when acpi specific uart initialization function is
> introduced.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
A
The cpu hotplug state machine in smpboot.c is reusing the states from
cpu.h. That is confusing when it comes to the CPU_DEAD_FROZEN usage.
Paul explained to me that he was in need of an additional state
for destinguishing between a CPU error states. For this he just
picked CPU_DEAD_FROZEN.
8038dad
>>> On 25.11.15 at 16:18, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1798,8 +1798,7 @@ static int hvm_save_cpu_ctxt(struct domain *d,
> hvm_domain_context_t *h)
>
> if ( v->fpu_initialised )
> memcpy(ctxt.fpu_regs, v->arch.fpu_ctxt, sizeof(c
On Thu, Nov 26, 2015 at 11:45:13AM +, Wei Liu wrote:
> On Tue, Nov 24, 2015 at 11:16:47PM -0500, Eric Shelton wrote:
> [...]
> >
> > > I discussed with Stefano and Anthony to reassess Linux-based stubdom,
> > > with all the issues mentioned above, if we narrow down the scope of
> > > the proje
On 26/11/15 13:48, Malcolm Crossley wrote:
> On 26/11/15 13:46, Jan Beulich wrote:
> On 25.11.15 at 11:28, wrote:
>>> The problem is that SandyBridge IOMMUs advertise 2M support and do
>>> function with it, but cannot cache 2MB translations in the IOTLBs.
>>>
>>> As a result, attempting to use
On Thu, 2015-11-26 at 21:23 +0800, Big Strong wrote:
> Is hypercall page a reference (api) to hypercall functions (handlers)
> or a standalone hypercall function collections? Can anybody tell me
> what is the code in the page?
>
Have you tried asking Google? (Or our Wiki? Or a Xen book? Or the Xen
On 26/11/15 13:46, Jan Beulich wrote:
On 25.11.15 at 11:28, wrote:
>> The problem is that SandyBridge IOMMUs advertise 2M support and do
>> function with it, but cannot cache 2MB translations in the IOTLBs.
>>
>> As a result, attempting to use 2M translations causes substantially
>> worse per
>>> On 25.11.15 at 11:28, wrote:
> The problem is that SandyBridge IOMMUs advertise 2M support and do
> function with it, but cannot cache 2MB translations in the IOTLBs.
>
> As a result, attempting to use 2M translations causes substantially
> worse performance than 4K translations.
Btw - how d
On 26/11/15 13:27, Jan Beulich wrote:
> The way we populate mpc_cpufeature is not compatible with modern CPUs,
> and hence the message printed using that information is useless/bogus.
> It's of interest only anyway when not using ACPI, so move it into MPS
> parsing code. This at once significantly
The way we populate mpc_cpufeature is not compatible with modern CPUs,
and hence the message printed using that information is useless/bogus.
It's of interest only anyway when not using ACPI, so move it into MPS
parsing code. This at once significantly reduces boot time logging on
huge systems.
Si
Is hypercall page a reference (api) to hypercall functions (handlers) or a
standalone hypercall function collections? Can anybody tell me what is the
code in the page?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
flight 65109 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65109/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail REGR. vs. 59254
test-amd64-amd64-xl-p
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Parth Dixit
>
> Parse GTDT (Generic Timer Descriptor Table) to initialize timer. Using
> the information presented by GTDT to initialize the arch timer (not
> memory-mapped).
>
> Signed-off-by: Naresh Bhat
> Signed-off-by: Parth Dixit
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Add a helper funtion to get the type of interrupts in ACPI table.
>
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/acpi/lib.c| 27 +++
> xen/include/asm-arm/acpi.h | 39
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Parth Dixit
>
> Add a helper function to set edge/level type information for an
> interrupt.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/irq.c| 22 +++---
> xen/include/as
>>> On 20.11.15 at 17:03, wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -10,6 +10,8 @@
> #include
> #include
>
> +DEFINE_PER_CPU(cpumask_t, percpu_rwlock_readers);
static (and perhaps even local to _percpu_write_lock()).
> @@ -492,6 +494,42 @@ int _rw_is_write_loc
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Parth Dixit
>
> With ACPI 5.0, we got per-processor timer support in GTDT,
> and ACPI 5.1 introduced the support for platform (memory-mapped)
> timers: GT Block and SBSA watchdog timer, add the code needed
> for the spec change.
>
> Sig
> On 26 Nov 2015, at 12:11, Wei Liu wrote:
>
> Dave, ping?
Sorry, completely forgot about this email.
Looks totally fine to me!
Acked-by: David Scott
Cheers,
Dave
>
> On Mon, Nov 16, 2015 at 12:43:19PM +, Wei Liu wrote:
>> According to public/sched.h, there is a new shutdown_reason ca
Dave, ping?
On Mon, Nov 16, 2015 at 12:43:19PM +, Wei Liu wrote:
> According to public/sched.h, there is a new shutdown_reason called
> soft_reset. Propagate that value to ocaml.
>
> Signed-off-by: Wei Liu
> ---
> Cc: David Scott
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbe
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Since ACPI 6.0 defines that GIC Distributor Structure contains the GIC
> version filed, it could get GIC version from that. According to the
> version, call different preinit functions.
>
> Signed-off-by: Shannon Zhao
On Fri, Nov 20, 2015 at 09:55:12AM +, Paul Durrant wrote:
> The Microsoft Hypervisor Top Level Functional Spec. (section 3.4) defines
> two bits in CPUID leaf 0x4004:EAX for the hypervisor to recommend
> whether or not to issue a hypercall for local or remote TLB flush.
>
> Whilst it's dou
>>> On 26.11.15 at 12:42, wrote:
> Also, on further consideration, the better fix (however we identify the
> affected systems) would be to quirk the IOMMUs themselves into not
> claiming 2M/1G superpage support.
>
> Otherwise, when we do eventually get superpage IOMMU mapping support in
> the API
On Tue, Nov 24, 2015 at 11:16:47PM -0500, Eric Shelton wrote:
[...]
>
> > I discussed with Stefano and Anthony to reassess Linux-based stubdom,
> > with all the issues mentioned above, if we narrow down the scope of
> > the project -- ignore BSD support for now, integrate build with
> > Raisin, no
On 26/11/15 10:39, Jan Beulich wrote:
On 26.11.15 at 11:27, wrote:
>> On 26/11/15 08:45, Jan Beulich wrote:
>> On 25.11.15 at 16:58, wrote:
On 25/11/15 15:38, Jan Beulich wrote:
On 25.11.15 at 16:13, wrote:
>> On 25/11/15 10:49, Jan Beulich wrote:
>>> And finally I
On Thu, 2015-11-26 at 03:38 -0700, Jan Beulich wrote:
> > > > On 26.11.15 at 10:51, wrote:
> > On Thu, 2015-11-26 at 00:43 -0700, Jan Beulich wrote:
> > > > > > On 25.11.15 at 17:26, wrote:
> > > > On Wed, 2015-11-25 at 09:16 -0700, Jan Beulich wrote:
> > > > > The use of $(basename ...) here was
>>> On 26.11.15 at 11:27, wrote:
> On 26/11/15 08:45, Jan Beulich wrote:
> On 25.11.15 at 16:58, wrote:
>>> On 25/11/15 15:38, Jan Beulich wrote:
>>> On 25.11.15 at 16:13, wrote:
> On 25/11/15 10:49, Jan Beulich wrote:
>> And finally I'm not fully convinced using CPU model info t
>>> On 26.11.15 at 10:51, wrote:
> On Thu, 2015-11-26 at 00:43 -0700, Jan Beulich wrote:
>> > > > On 25.11.15 at 17:26, wrote:
>> > On Wed, 2015-11-25 at 09:16 -0700, Jan Beulich wrote:
>> > > The use of $(basename ...) here was wrong (yet I'm sure I tested it).
>> >
>> > Is the issue here that
On 26/11/15 08:45, Jan Beulich wrote:
On 25.11.15 at 16:58, wrote:
>> On 25/11/15 15:38, Jan Beulich wrote:
>> On 25.11.15 at 16:13, wrote:
On 25/11/15 10:49, Jan Beulich wrote:
> And finally I'm not fully convinced using CPU model info to deduce
> chipset behavior is entire
El 16/11/15 a les 19.33, Andrew Cooper ha escrit:
> On 16/11/15 12:18, Jan Beulich wrote:
> On 06.11.15 at 17:05, wrote:
>>> --- a/xen/include/public/arch-x86/xen.h
>>> +++ b/xen/include/public/arch-x86/xen.h
>>> @@ -265,7 +265,31 @@ typedef struct arch_shared_info arch_shared_info_t;
>>> *
On Wed, Nov 25, 2015 at 04:56:09PM -0500, Boris Ostrovsky wrote:
> getpwnam_r() has fairly complicated return rules. From man pages:
>
> RETURN VALUE
> ...
> On success, getpwnam_r() and getpwuid_r() return zero, and set
> *result to pwd. If no matching password record was fo
On Thu, 2015-11-26 at 10:03 +, Ian Campbell wrote:
> On Wed, 2015-11-25 at 16:56 -0500, Boris Ostrovsky wrote:
> > getpwnam_r() has fairly complicated return rules. From man pages:
> >
> > RETURN VALUE
> > ...
> > On success, getpwnam_r() and getpwuid_r() return zero, and set
> >
On Wed, 2015-11-25 at 16:56 -0500, Boris Ostrovsky wrote:
> getpwnam_r() has fairly complicated return rules. From man pages:
>
> RETURN VALUE
> ...
> On success, getpwnam_r() and getpwuid_r() return zero, and set
> *result to pwd. If no matching password record was found, th
On Thu, 2015-11-26 at 00:43 -0700, Jan Beulich wrote:
> > > > On 25.11.15 at 17:26, wrote:
> > On Wed, 2015-11-25 at 09:16 -0700, Jan Beulich wrote:
> > > The use of $(basename ...) here was wrong (yet I'm sure I tested it).
> >
> > Is the issue here that xen/arch/x86/x86_64/.compat.o.d ought rea
[Cc-list edited]
On Wed, 2015-11-25 at 08:58 +, Malcolm Crossley wrote:
> On 24/11/15 18:30, George Dunlap wrote:
> > On 24/11/15 18:16, George Dunlap wrote:
> > > On 20/11/15 16:03, Malcolm Crossley wrote:
> > > >
> > > > Removing the cache line bouncing on a multi-socket Haswell-EP
> > > >
On Thu, 2015-11-26 at 01:55 -0700, Jan Beulich wrote:
> > > > On 25.11.15 at 20:32, wrote:
> > flight 65094 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/65094/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests whic
On Wed, 2015-11-25 at 16:56 -0500, Boris Ostrovsky wrote:
> getpwnam_r() has fairly complicated return rules. From man pages:
>
> RETURN VALUE
> ...
> On success, getpwnam_r() and getpwuid_r() return zero, and set
> *result to pwd. If no matching password record was found,
>
We've been told by Intel that server chipsets don't need the workaround
anymore starting with Ivybridge (Xeon E5/E7 v2); the second half of the
workaround was missing anyway.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -432,
flight 38352 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38352/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 38310
build-a
>>> On 25.11.15 at 20:32, wrote:
> flight 65094 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/65094/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-rumpuserxen-i386 10 guest-start
>>> On 25.11.15 at 16:58, wrote:
> On 25/11/15 15:38, Jan Beulich wrote:
> On 25.11.15 at 16:13, wrote:
>>> On 25/11/15 10:49, Jan Beulich wrote:
And finally I'm not fully convinced using CPU model info to deduce
chipset behavior is entirely correct (albeit perhaps in practice it'll
Am Dienstag 24 November 2015, 15:53:12 schrieb Brendan Gregg:
> This introduces a way to have a restricted VPMU, by specifying one of two
> predefined groups of PMCs to make available. For secure environments, this
> allows the VPMU to be used without needing to enable all PMCs.
>
> Signed-off-by:
84 matches
Mail list logo
