flight 58745 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58745/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 58663
test-armhf-armhf-xl
flight 58768 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58768/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866
build-amd64-rumpuserx
Signed-off-by: Boris Ostrovsky
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
---
tools/libxc/xc_dom_x86.c | 32 +++-
1 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 9
Signed-off-by: Boris Ostrovsky
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
---
xen/arch/x86/domain.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d049fa8..f87da64 100644
--- a/xen/arch/x86/domain.c
+++ b/xe
.. since it doesn't exist for PVH.
Signed-off-by: Boris Ostrovsky
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
---
xen/arch/x86/mm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9e08c9b..eb369bd 100644
--- a/xen/ar
Managing l4 page table and argument translation area are two unrelated
operations and should be handled separately
Signed-off-by: Boris Ostrovsky
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
---
xen/arch/x86/domain.c | 36 ++--
1 files changed, 26 inser
.. as this field is not used by PVH guests
Signed-off-by: Boris Ostrovsky
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
---
xen/arch/x86/domain.c |9 ++---
xen/arch/x86/domctl.c |9 ++---
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/domain.
.. based on whether the guest is 32- or 64-bit
Signed-off-by: Boris Ostrovsky
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
---
xen/arch/x86/domain.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index c7ef1e6..ba2
Instead of assuming that the PVH guest is 64-bit during VMCS constructions and
overriding 32/64 bit settings in VMCS later we can keep HVM's settings and
update them as needed when we know exactly what the guest is.
Signed-off-by: Boris Ostrovsky
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Coope
vcpu_guest_context's fs_base, gs_base_kernel and gs_base_user are not defined
for 32-bit guests.
Drop PVH 32bitfixme ASSERT.
Signed-off-by: Boris Ostrovsky
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
---
xen/arch/x86/domain.c |8 +++-
1 files changed, 3 insertions(+), 5 deleti
Initial 32-bit PVH support, dom0 will need more work.
Boris Ostrovsky (9):
x86/pvh: Don't test 64b-only vcpu_guest_context's fields
x86/pvh: Don't copy to/from trap_ctxt for 32b PVH guests
x86/pvh: Properly initialize PVH guest's CR3
x86/compat: Manage argument translation area separately
vcpu_guest_context's fs_base, gs_base_kernel and gs_base_user are not defined
for 32-bit guests.
Drop PVH 32bitfixme ASSERT.
Signed-off-by: Boris Ostrovsky
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
---
xen/arch/x86/domain.c |8 +++-
1 files changed, 3 insertions(+), 5 deleti
Signed-off-by: Boris Ostrovsky
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 35 +--
1 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c3c129d..12f6839 100644
flight 58744 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58744/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt 11 guest-start fail like 58620
test-amd64-amd64-libvirt 11
flight 58737 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 14 guest-start.2 fail REGR. vs. 58620
Regressions which are
On Wed, Jun 17, 2015 at 09:31:16PM +0100, Al Viro wrote:
> On Wed, Jun 17, 2015 at 10:57:15AM +0200, Jan Kara wrote:
> > > Joy... Folks, is anybody actively maintaining fs/ufs these days?
> >
> > Looking into the changelog there wasn't anyone seriously looking into UFS
> > for at least 5-6 years.
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
Now that we have pci_iomap_wc() add the respective devres helpers.
Cc: Toshi Kani
Cc: Andy Lutomirski
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Bjorn Helgaas
Cc: Antonino Daplas
Cc: Jean-Chris
From: "Luis R. Rodriguez"
PCI BARs tell us whether prefetching is safe, but they don't say anything
about write combining (WC). WC changes ordering rules and allows writes to
be collapsed, so it's not safe in general to use it on a prefetchable
region.
Add pci_iomap_wc() and pci_iomap_wc_range(
From: "Luis R. Rodriguez"
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage o
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
This lets drivers take advantage of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache() (de33c442e titled
From: "Luis R. Rodriguez"
Arnd,
After a long-winded conversation with Bjorn over use of
EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL() he's noted he'd
be OK if this goes through you as an alternative. This series
goes unmodified from the last posted v6 series, I am just
reposting and addressing
flight 58736 xen-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58736/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 3 host-install(3) broken in 58584 REGR. vs. 584
On Fri, Jun 19, 2015 at 4:06 PM, Luis R. Rodriguez
wrote:
> I hope to have provided a bit of new information to help you
> reconsider this series to go through you but since you seem to be fine
> for this to go through another tree and since I failed to notice that
> I should also get Arnd's Ack
flight 58738 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58738/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt-xsm 11 guest-start fail like 58713
test-amd64-i386-libvirt 11 gu
On Tue, Jun 16, 2015 at 3:20 PM, Bjorn Helgaas wrote:
> On Tue, Jun 16, 2015 at 2:16 PM, Luis R. Rodriguez
> wrote:
>> On Thu, May 28, 2015 at 5:36 PM, Luis R. Rodriguez
>> wrote:
>>> On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez wrote:
On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn
On Tue, Jun 09, 2015 at 10:21:27AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 09, 2015 at 04:07:33PM +0200, Roger Pau Monn? wrote:
> > El 09/06/15 a les 15.39, Konrad Rzeszutek Wilk ha escrit:
> > > On Tue, Jun 09, 2015 at 08:52:53AM +, Paul Durrant wrote:
> > >>> -Original Message--
On 06/19/2015 10:54 AM, Eric Blake wrote:
On 06/19/2015 10:33 AM, Ian Campbell wrote:
If vm->def->cputune.nvcpupin is 0 in libxlDomainSetVcpuAffinities (as
seems to be the case on arm) then the VIR_FREE after cleanup: would be
operating on an uninitialised pointer in map.map.
Fix this by using
Add pmu.h header files, move various macros and structures that will be
shared between hypervisor and PV guests to it.
Move MSR banks out of architectural PMU structures to allow for larger sizes
in the future. The banks are allocated immediately after the context and
PMU structures store offsets
Add support for privileged PMU mode (XENPMU_MODE_ALL) which allows privileged
domain (dom0) profile both itself (and the hypervisor) and the guests. While
this mode is on profiling in guests is disabled.
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
---
xen/arch/x86/hvm/vpmu.c | 40
The two routines share most of their logic.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Dietmar Hahn
---
xen/arch/x86/hvm/vpmu.c| 75 --
xen/include/asm-x86/hvm/vpmu.h | 14 ++--
2 files changed, 41 insertions(+), 48 deletions(-)
diff --git a
A number of fields of PMU control MSRs are defined as Reserved. AMD
documentation requires that such fields are preserved when the register
is written by software.
Add checks to amd_vpmu_do_wrmsr() to make sure that guests don't attempt
to modify those bits.
Signed-off-by: Boris Ostrovsky
---
x
Code for initializing/tearing down PMU for PV guests
Signed-off-by: Boris Ostrovsky
Acked-by: Daniel De Graaf
Acked-by: Jan Beulich
Acked-by: Kevin Tian
---
tools/flask/policy/policy/modules/xen/xen.te | 4 +
xen/arch/x86/domain.c| 2 +
xen/arch/x86/hvm/hvm.c
Hypervisor cannot easily inject faults into PV guests from arch-specific VPMU
read/write MSR handlers (unlike it is in the case of HVM guests).
With this patch vpmu_do_msr() will return an error code to indicate whether an
error was encountered during MSR processing (instead of stating that the ac
Move some VPMU initilization operations into __initcalls to avoid performing
same tests and calculations for each vcpu.
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
---
xen/arch/x86/hvm/svm/vpmu.c | 106 --
xen/arch/x86/hvm/vmx/vpmu_core2.c | 151 ++
Since PMU is now not HVM specific we can move VPMU-related files up from
arch/x86/hvm/ directory.
Specifically:
arch/x86/hvm/vpmu.c -> arch/x86/cpu/vpmu.c
arch/x86/hvm/svm/vpmu.c -> arch/x86/cpu/vpmu_amd.c
arch/x86/hvm/vmx/vpmu_core2.c -> arch/x86/cpu/vpmu_intel.c
include/asm-x86/h
Add support for handling PMU interrupts for PV(H) guests.
VPMU for the interrupted VCPU is unloaded until the guest issues XENPMU_flush
hypercall. This allows the guest to access PMU MSR values that are stored in
VPMU context which is shared between hypervisor and domain, thus avoiding
traps to hy
No need to compute those masks on every MSR access.
Also, when checking MSR_P6_EVNTSELx registers make sure that bit 21
(which is a reserved bit) is not set.
Signed-off-by: Boris Ostrovsky
Acked-by: Kevin Tian
---
xen/arch/x86/hvm/vmx/vpmu_core2.c | 28 ++--
1 file chan
Intercept accesses to PMU MSRs and process them in VPMU module. If vpmu ops
for VCPU are not initialized (which is the case, for example, for PV guests that
are not "VPMU-enlightened") access to MSRs will return failure.
Dump VPMU state for all domains (HVM and PV) when requested.
Signed-off-by:
Add runtime interface for setting PMU mode and flags. Three main modes are
provided:
* XENPMU_MODE_OFF: PMU is not virtualized
* XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
* XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
can profile itself
Export Xen's symbols as {} triplet via new XENPF_get_symbol
hypercall
Signed-off-by: Boris Ostrovsky
Acked-by: Daniel De Graaf
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/platform_hypercall.c | 28 +++
xen/common/sym
Changes in v25:
* Add extra check for consistency in patch 4
* Replace few returns with 'ret = -E...' (patches 4 and 12)
* Clarified commit message in patch 8
* A couple of cosmetic changes in patch 12
(I left AMD multi-counter problem unfixed since what I thought would
be sufficient to fix it did
Save VPMU state during context switch for both HVM and PV(H) guests.
A subsequent patch ("x86/VPMU: NMI-based VPMU support") will make it possible
for vpmu_switch_to() to call vmx_vmcs_try_enter()->vcpu_pause() which needs
is_running to be correctly set/cleared. To prepare for that, call
context_
vpmu structure will be used for both HVM and PV guests. Move it from
hvm_vcpu to arch_vcpu.
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
Reviewed-by: Kevin Tian
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/include/asm-x86/domain.h | 2 ++
xen/include/asm-x86/hvm/vcpu.h
flight 58734 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58734/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 9 windows-installfail REGR. vs. 58723
Regressions which are regard
flight 58732 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58732/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs.
58721
Regressions whic
On 19/06/15 14:04, Jan Beulich wrote:
On 19.06.15 at 14:23, wrote:
>> On 19/06/15 11:55, Jan Beulich wrote:
>> On 19.06.15 at 11:52, wrote:
On 19/06/15 10:29, Jan Beulich wrote:
On 18.06.15 at 12:40, wrote:
>> On 18/06/15 11:36, Jan Beulich wrote:
>> On 17.06.1
On 06/19/2015 10:33 AM, Ian Campbell wrote:
> If vm->def->cputune.nvcpupin is 0 in libxlDomainSetVcpuAffinities (as
> seems to be the case on arm) then the VIR_FREE after cleanup: would be
> operating on an uninitialised pointer in map.map.
>
> Fix this by using libxl_bitmap_init and libxl_bitmap_
If vm->def->cputune.nvcpupin is 0 in libxlDomainSetVcpuAffinities (as
seems to be the case on arm) then the VIR_FREE after cleanup: would be
operating on an uninitialised pointer in map.map.
Fix this by using libxl_bitmap_init and libxl_bitmap_dispose in the
appropriate places (like VIR_FREE libxl
On Fri, Jun 19, 2015 at 01:05:55PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH OSSTEST v3 12/11] toolstack/libvirt: install
> libnl-3-200 on Jessie"):
> > Signed-off-by: Wei Liu
> ...
> > diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
> > index e7f4860..c71f88a 1
flight 58731 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58731/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect
test-amd64-amd64-pair
Ian Campbell writes ("[PATCH OSSTEST] ts-libvirt-build: Enable debug symbols in
binaries"):
> ... by passing -g as appropriate.
>
> Also ensure debug logging is enabled with --enable-debug (which
> doesn't imply -g during build!).
>
> Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
And bun
On 19/06/15 17:02, Boris Ostrovsky wrote:
> On 06/19/2015 11:15 AM, Ross Lagerwall wrote:
>> When a CPU is offlined, there may be unprocessed events on a port for
>> that CPU. If the port is subsequently reused on a different CPU, it
>> could be in an unexpected state with the link bit set, result
On 06/19/2015 11:15 AM, Ross Lagerwall wrote:
When a CPU is offlined, there may be unprocessed events on a port for
that CPU. If the port is subsequently reused on a different CPU, it
could be in an unexpected state with the link bit set, resulting in
interrupts being missed. Fix this by consumi
On Fri, Jun 19, 2015 at 02:21:51PM +0200, Imre Palik wrote:
> From: "Palik, Imre"
>
> Commit edafc132baac ("xen-netback: making the bandwidth limiter runtime
> settable")
> introduced the capability to change the bandwidth rate limit at runtime.
> But it also introduced a possible crashing bug.
... by passing -g as appropriate.
Also ensure debug logging is enabled with --enable-debug (which
doesn't imply -g during build!).
Signed-off-by: Ian Campbell
---
ts-libvirt-build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ts-libvirt-build b/ts-libvirt-build
index 3
When a CPU is offlined, there may be unprocessed events on a port for
that CPU. If the port is subsequently reused on a different CPU, it
could be in an unexpected state with the link bit set, resulting in
interrupts being missed. Fix this by consuming any unprocessed events
for a particular CPU w
>>> On 19.06.15 at 16:07, wrote:
> I don't mind adding a PHYSDEVOP_pci_mmcfg_reserved call to FreeBSD, but
> for it to have any effect we need to stop unconditionally mapping
> everything as MMIO regions on PVH Dom0.
Right, I didn't mean to imply PVH would have any chance of working
right now.
B
On Fri, Jun 19, 2015 at 02:50:34PM +0100, Ian Campbell wrote:
> On Wed, 2015-06-17 at 14:06 +0100, Wei Liu wrote:
> > +case $suite_$arch in
>
> Sorry, this is buggy, it looks for a variable named "suite_" which
> doesn't exist and so nothing matches. It needs this:
>
> diff --git a/mg-debian-inst
>>> On 19.06.15 at 15:05, wrote:
>>And now that I started looking into what it takes to make this
>>work, I'm having a deja vu: In order for us to reliably intercept
>>all CFG accesses, we need to whitelist the MMCFG pages of
>>devices we know we don't care about being written. I.e. we
>>need to s
On Thu, Jun 18, 2015 at 10:35:37AM +0100, Jan Beulich wrote:
> >>> On 18.06.15 at 11:18, wrote:
> > Jan Beulich wrote on 2015-06-18:
> > On 18.06.15 at 10:53, wrote:
> >>> Jan Beulich wrote on 2015-06-18:
> >>> On 18.06.15 at 10:20, wrote:
> > Apart from that I notice that the EXIT_R
El 19/06/15 a les 15.00, Jan Beulich ha escrit:
On 11.06.15 at 11:51, wrote:
>> On 11/06/15 09:35, Jan Beulich wrote:
>>> While I continue to be of the opinion that all direct writes to
>>> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask,
>>> MSI per entry mask) outside of the hy
Hi all,
The Raisin git repository has just moved out of my personal git space on
xenbits to a more official location. The new git Raisin URL is:
git://xenbits.xen.org/raisin.git
http://xenbits.xen.org/gitweb/?p=raisin.git
Cheers,
Stefano
___
Xen-deve
On Wed, 2015-06-17 at 14:06 +0100, Wei Liu wrote:
> +case $suite_$arch in
Sorry, this is buggy, it looks for a variable named "suite_" which
doesn't exist and so nothing matches. It needs this:
diff --git a/mg-debian-installer-update b/mg-debian-installer-update
index b9b1146..6a26675 100755
---
Ian Campbell writes ("Re: [OSSTEST PATCH 2/2] config: Computed defaults for
Logs and Results"):
> On Fri, 2015-06-19 at 13:38 +0100, Ian Jackson wrote:
> > Signed-off-by: Ian Jackson
>
> No functional change AFAICT.
Indeed.
I have collected these and your --reuse patch into a branch of
miscell
Hi,
On 6/18/2015 10:54 PM, Ian Campbell wrote:
On Thu, 2015-06-18 at 22:09 +0800, Peng Fan wrote:
Hi,
I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have
no clear idea about why Dom0 kernel panic.
Have you confirmed that this same kernel runs reliably natively on this
plat
On Fri, Jun 19, 2015 at 10:58:25AM +0200, Roger Pau Monne wrote:
> argp is only present in the GNU C library, so add a specific check for it in
> configure. Also check if -largp is needed for linking against it.
>
> Please run autoconf after applying.
>
> Signed-off-by: Roger Pau Monné
> Cc: Geo
On Fri, Jun 19, 2015 at 10:58:24AM +0200, Roger Pau Monne wrote:
> This is not needed, neither encouraged. Configure already checks
> _FILE_OFFSET_BITS and appends it when needed, so that the right functions
> are used. Also remove the usage of loff_t and O_LARGEFILE for the same
> reason.
>
> Sig
On June 19, 2015 9:00:39 AM EDT, Jan Beulich wrote:
On 11.06.15 at 11:51, wrote:
>> On 11/06/15 09:35, Jan Beulich wrote:
>>> While I continue to be of the opinion that all direct writes to
>>> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask,
>>> MSI per entry mask) outside of t
>>> On 19.06.15 at 14:23, wrote:
> On 19/06/15 11:55, Jan Beulich wrote:
> On 19.06.15 at 11:52, wrote:
>>> On 19/06/15 10:29, Jan Beulich wrote:
>>> On 18.06.15 at 12:40, wrote:
> On 18/06/15 11:36, Jan Beulich wrote:
> On 17.06.15 at 14:02, wrote:
>>> --- a/xen/common/
>>> On 11.06.15 at 11:51, wrote:
> On 11/06/15 09:35, Jan Beulich wrote:
>> While I continue to be of the opinion that all direct writes to
>> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask,
>> MSI per entry mask) outside of the hypervisor are wrong and
>> should be eliminated, the s
On Fri, 2015-06-19 at 13:38 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson
No functional change AFAICT.
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, 2015-06-19 at 13:38 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
When the property "clock-frequency" is present in the DT timer node, it
means that the bootloader/firmware didn't correctly configure the
CNTFRQ/CNTFRQ_EL0 on each processor.
The best solution would be to fix the offending firmware/bootloader,
although it may not always be possible to modify and r
Signed-off-by: Ian Jackson
---
Osstest.pm |3 ++-
production-config |1 -
production-config-cambridge |1 -
3 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Osstest.pm b/Osstest.pm
index 8948666..fc46487 100644
--- a/Osstest.pm
+++ b/Osstest.pm
Signed-off-by: Ian Jackson
---
Osstest.pm |9 +++--
production-config |2 --
production-config-cambridge |2 --
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/Osstest.pm b/Osstest.pm
index fc46487..c89c941 100644
--- a/Osstest.pm
+++ b/Os
Wei Liu writes ("[PATCH OSSTEST v3 02/11] mg-debian-installer-update: updates
to better handle Jessie onwards."):
> From: Ian Campbell
>
> In mg-debian-installer-update:
>
> - Expand the list of (suite,arch) combinations which don't exist and
> move it to the top.
...
> -# Newer kerne
flight 58730 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58730/
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. 58451
test-amd64-amd64
On 19/06/15 11:55, Jan Beulich wrote:
On 19.06.15 at 11:52, wrote:
>> On 19/06/15 10:29, Jan Beulich wrote:
>> On 18.06.15 at 12:40, wrote:
On 18/06/15 11:36, Jan Beulich wrote:
On 17.06.15 at 14:02, wrote:
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/ev
Wei Liu writes ("[PATCH OSSTEST v3 09/11] ts-xen-build-prep: reverse the test
for installing libc6-dev-i386"):
> Starting from wheezy, Debian introduced multiarch support, so we need to
> install libc6-dev-i386 to build tools.
>
> Since multiarch will be permanent, we reverse the test to not inst
From: "Palik, Imre"
Commit edafc132baac ("xen-netback: making the bandwidth limiter runtime
settable")
introduced the capability to change the bandwidth rate limit at runtime.
But it also introduced a possible crashing bug.
If netback receives two XenbusStateConnected without getting the
hotplu
Wei Liu writes ("[PATCH OSSTEST v3 06/11] Cope with Jessie's d-i vg name"):
> In Jessie the default vg name is changed to "$hostname-vg". Make that
> default case and check for wheezy, squeeze and lenny for backward
> compatibility.
>
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
Wei Liu writes ("[PATCH] libxc: delete sent_last_iter"):
> It's set in code but never used. Detected by -Wunused-but-set-variable.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Ian Jackson writes ("RE: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe
of nested test job"):
...
> But it isn't as simple as you suggest, unfortunately. Because:
>
> > proc need-hosts/test-nested {} {return host}
> > proc run-job/test-nested {} {
> > run-ts . = ts-debian-hvm-install
Pang, LongtaoX writes ("RE: [OSSTEST Nested PATCH v11 6/7] Compose the main
recipe of nested test job"):
> So, may I implement these action via below recipe in sg-run-job? Since, this
> would be less code to
> be changed and we want to avoid to involve tcl plumbing in sg-run-job. Also,
> I thin
Hi all,
I created two pages to help assignment of BoF's and topics that we should cover
in the Developer Meeting the day after Developer Summit. You can sign up for
BoF's and the Developer Meeting by replying to this mail or by editing the
following two wiki pages
* http://wiki.xenproject.org/w
On 06/19/2015 02:04 PM, Jan Beulich wrote:
On 19.06.15 at 13:06, <"jgr...@suse.com".non-mime.internet> wrote:
The console information of dom0 is living in the same memory page as the
start_info data. Don't put the console data directly after the start_info
to leave some room for future structure
Wei Liu writes ("[PATCH OSSTEST v3 12/11] toolstack/libvirt: install
libnl-3-200 on Jessie"):
> Signed-off-by: Wei Liu
...
> diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
> index e7f4860..c71f88a 100644
> --- a/Osstest/Toolstack/libvirt.pm
> +++ b/Osstest/Toolstack/libv
>>> On 19.06.15 at 13:06, <"jgr...@suse.com".non-mime.internet> wrote:
> The console information of dom0 is living in the same memory page as the
> start_info data. Don't put the console data directly after the start_info
> to leave some room for future structure enlargements. Otherwise a dom0
> wi
flight 58728 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58728/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail in 58717
REGR. vs. 58528
Tests
Il 11/06/2015 12:28, Fabio Fantoni ha scritto:
Il 11/06/2015 12:06, Zir Blazer ha scritto:
Since I'm not a developer I may be peeking my nose a bit too far, but
based on what I know, I think that enabling AHCI by default would be
a compatibility suicide. I'm not sure about Linux and Windows
Vi
On Fri, 2015-06-19 at 12:02 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot
> order during install"):
> > On Thu, 2015-06-18 at 18:57 +0100, Ian Jackson wrote:
> > > This seems a pretty serious bug. Is there a way to avoid it ?
> >
> > Unfor
On Fri, 2015-06-19 at 12:04 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST v2 13/19] standalone: Prefer
> ./standalone.config to $HOME/.xen-osstest/config"):
> > On Fri, 2015-06-19 at 11:22 +0100, Ian Campbell wrote:
> > > On Thu, 2015-06-18 at 18:59 +0100, Ian Jackson wrote:
On Fri, 2015-06-19 at 10:51 +0100, Jan Beulich wrote:
> >>> On 18.06.15 at 16:22, wrote:
> > On Thu, 2015-06-18 at 12:37 +0100, Jan Beulich wrote:
> >> >>> On 17.06.15 at 12:26, wrote:
> >> > Jan Beulich writes ("stable trees (was: [xen-4.2-testing test] 58584:
> >> > regressions)"):
> >> >> Whi
The comments describing the initial pv-domain memory layout are not
complete. They do not mention the pages with console info and xenstore
data.
Add this information to the comments.
Signed-off-by: Juergen Gross
---
xen/include/public/xen.h | 17 ++---
1 file changed, 10 insertions(
The console information of dom0 is living in the same memory page as the
start_info data. Don't put the console data directly after the start_info
to leave some room for future structure enlargements. Otherwise a dom0
with a newer start_info layout than the hypervisor could interprete
console data
1 - 100 of 133 matches
Mail list logo
