flight 79162 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79162/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399
build-amd64-rumpuserxen
flight 79168 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79168/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail
REGR. vs. 65543
test-amd64-i386-
.linux.opic.d
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror
-Wmissing-prototypes -I./include
-I/home/www/builds_xen_unstable/xen-src-2e46e3f2-20160127/tools/libs/evtchn/../../../tools/include
-I/home/www/builds_xen_unstable/xen-src-2e46e3f2-20160127/tools/libs/evtchn
flight 79158 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79158/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 9 debian-di-install fail REGR. vs. 78977
test-armhf-armhf-libvi
Enable VT-d Posted-Interrupts and add a command line
parameter for it.
CC: Jan Beulich
Signed-off-by: Feng Wu
Reviewed-by: Kevin Tian
Acked-by: Jan Beulich
---
docs/misc/xen-command-line.markdown | 9 -
xen/drivers/passthrough/iommu.c | 3 +++
2 files changed, 11 insertions(+), 1
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
You can find the VT-d Posted-Interrtups Spec. in
This is the core logic handling for VT-d posted-interrupts. Basically it
deals with how and when to update posted-interrupts during the following
scenarios:
- vCPU is preempted
- vCPU is slept
- vCPU is blocked
When vCPU is preempted/slept, we update the posted-interrupts during
scheduling by intr
On 01/27/2016 02:09 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 27, 2016 at 02:25:51PM -0600, Doug Goldstein wrote:
>> On 1/27/16 12:32 PM, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
I would like to hear the community's opinion on supporting
On 01/27/2016 01:25 PM, Doug Goldstein wrote:
> On 1/27/16 12:32 PM, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
>>> I would like to hear the community's opinion on supporting more qdisk types
>>> in
>>> xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer
From: Shannon Zhao
Refactor gic-v3 related functions into dt and generic parts. This will be
helpful when adding acpi support for gic-v3.
Signed-off-by: Shannon Zhao
---
v6: keep vsize check in gicv3_init_v2
---
xen/arch/arm/gic-v3.c | 84 +++
1
On 01/27/2016 11:32 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
>> I would like to hear the community's opinion on supporting more qdisk types
>> in
>> xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer supporting additional qdisk
>> types
>> in libxl
flight 79155 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79155/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 59254
test-armhf-armhf-xl-c
On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote:
On Fri, 15 Jan 2016, Leonid Yegoshin wrote:
So you need to build a different kernel for some types of MIPS systems?
Or do you do boot-time rewriting, like a number of other arches do?
I don't know. I would like to have responses. Ralf asked Maci
On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote:
On Fri, 15 Jan 2016, Leonid Yegoshin wrote:
So you need to build a different kernel for some types of MIPS systems?
Or do you do boot-time rewriting, like a number of other arches do?
I don't know. I would like to have responses. Ralf asked Maci
On Wed, Jan 27, 2016 at 10:04:47AM +0800, Boqun Feng wrote:
> On Tue, Jan 26, 2016 at 03:29:21PM -0800, Paul E. McKenney wrote:
> > On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote:
> > > On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds
> > > wrote:
> > > >
> > > > You might as well j
On Wed, Jan 27, 2016 at 02:57:07PM +, David Howells wrote:
> Peter Zijlstra wrote:
>
> > +==
> > +DISCLAIMER
> > +==
> > +
> > +This document is not a specification; it is intentionally (for the sake of
> > +brevity) and unintentionally (due to being human) incomplete. This
>
On Wed, Jan 27, 2016 at 10:25:46AM +, Will Deacon wrote:
> On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote:
> > On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote:
> > > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote:
> > > > On Mon, Jan 25, 2016 at 0
This run is configured for baseline tests only.
flight 38709 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38709/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 9 debian-di-in
On 01/27/2016 02:00 PM, Luis R. Rodriguez wrote:
On Wed, Jan 27, 2016 at 10:48 AM, Luis R. Rodriguez wrote:
Worth mentioning here also is hpa's clarification on when subarch type
PC (0) should be used: [it should be used if the hardware is]
"enumerable using standard PC mechanisms (PCI, ACPI) a
To help people avoid having to figure out what versions of make and
binutils need to be supported document them explicitly. The version of
binutils that had to be supported was mentioned in
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00609.html
as 2.17 recently. It was decided th
On 01/25/2016 02:47 AM, David Vrabel wrote:
> On 23/01/16 22:12, Sarah Newman wrote:
>> Greetings,
>>
>> We are having problems related to mptsas and "swiotlb buffer is full" with
>> the Xen4CentOS kernel (3.18). It looks like the last related work was
>> the series
>> http://lists.xenproject.org
flight 79145 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79145/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 60684
test-amd64
flight 79146 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79146/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass
test-armhf-armhf-libvirt-raw 11 migrate-sup
On Wed, Jan 27, 2016 at 02:25:51PM -0600, Doug Goldstein wrote:
> On 1/27/16 12:32 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
> >> I would like to hear the community's opinion on supporting more qdisk
> >> types in
> >> xl/libxl, e.g. nbd, rbd,
On 1/27/16 12:32 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
>> I would like to hear the community's opinion on supporting more qdisk types
>> in
>> xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer supporting additional qdisk
>> types
>> in libxl ov
On Wed, Jan 27, 2016 at 07:57:00PM +, Andrew Cooper wrote:
> On 27/01/2016 19:52, Konrad Rzeszutek Wilk wrote:
> >> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> >> index 674feea..7a15d49 100644
> >> --- a/xen/arch/x86/hvm/hvm.c
> >> +++ b/xen/arch/x86/hvm/hvm.c
> >> @@ -93,12
Extend the existing get_mem_access memop to allow querying permissions in
altp2m views as well.
Signed-off-by: Tamas K Lengyel
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Cc: Razvan Cojocaru
Cc: Stefano Stabellini
Cc: George Dunlap
Cc: Keir Fraser
Cc: Jan Beulich
The altp2m subsystem in its current form uses its own HVMOP hypercall to set
mem_access permissions, duplicating some of the code already present for
setting regular mem_access permissions. In this patch we consolidate the two,
deprecate the HVMOP hypercall and update the corresponding tools.
Sign
On Wed, Jan 27, 2016 at 12:42 PM, Razvan Cojocaru wrote:
> It is currently possible to leave a monitor flag enabled even
> after vm_event_cleanup_domain() has been called, potentially
> leading to a crash in hvm_msr_write_intercept() and hvm_set_crX()
> (when v->arch.vm_event has become NULL, but
On 27/01/2016 19:52, Konrad Rzeszutek Wilk wrote:
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index 674feea..7a15d49 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -93,12 +93,10 @@ unsigned long __section(".bss.page_aligned")
>> static bool_t __
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 674feea..7a15d49 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -93,12 +93,10 @@ unsigned long __section(".bss.page_aligned")
> static bool_t __initdata opt_hap_enabled = 1;
> boolean_param("hap", op
On 27/01/2016 19:42, Razvan Cojocaru wrote:
> It is currently possible to leave a monitor flag enabled even
> after vm_event_cleanup_domain() has been called, potentially
> leading to a crash in hvm_msr_write_intercept() and hvm_set_crX()
> (when v->arch.vm_event has become NULL, but the correspond
It is currently possible to leave a monitor flag enabled even
after vm_event_cleanup_domain() has been called, potentially
leading to a crash in hvm_msr_write_intercept() and hvm_set_crX()
(when v->arch.vm_event has become NULL, but the corresponding
corresponding v->domain->arch.monitor flag is no
On 01/27/2016 02:13 PM, Andrew Cooper wrote:
c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM domains to
unconditionally intercept #UD exceptions. While cross-vendor migration is
cool as a demo, it is extremely niche.
Intercepting #UD allows userspace code in a multi-vcpu guest t
On 27/01/16 19:14, Boris Ostrovsky wrote:
> On 01/27/2016 01:59 PM, Andrew Cooper wrote:
>> On 27/01/16 18:49, Boris Ostrovsky wrote:
>>> On 01/27/2016 01:11 PM, Andrew Cooper wrote:
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 1d71216..1084e82 100644
--- a/xen/ar
On 01/27/2016 01:59 PM, Andrew Cooper wrote:
On 27/01/16 18:49, Boris Ostrovsky wrote:
On 01/27/2016 01:11 PM, Andrew Cooper wrote:
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 1d71216..1084e82 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -65,8 +65,20 @@
c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM domains to
unconditionally intercept #UD exceptions. While cross-vendor migration is
cool as a demo, it is extremely niche.
Intercepting #UD allows userspace code in a multi-vcpu guest to execute
arbitrary instructions in the x86 emu
On Wed, Jan 27, 2016 at 10:48 AM, Luis R. Rodriguez wrote:
>
> Worth mentioning here also is hpa's clarification on when subarch type
> PC (0) should be used: [it should be used if the hardware is]
> "enumerable using standard PC mechanisms (PCI, ACPI) and doesn't need
> a special boot flow" -- do
On 27/01/16 18:49, Boris Ostrovsky wrote:
> On 01/27/2016 01:11 PM, Andrew Cooper wrote:
>> c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM
>> domains to
>> unconditionally intercept #UD exceptions. While cross-vendor
>> migration is
>> cool as a demo, it is extremely niche.
>>
>>
Bleh moving forward please use mcg...@kernel.org, that will be sent to
my employer and my personal address. More below.
On Wed, Jan 27, 2016 at 8:15 AM, Boris Ostrovsky
wrote:
> On 01/27/2016 10:29 AM, Konrad Rzeszutek Wilk wrote:
>> On Wed, Jan 27, 2016 at 10:17:56AM -0500, Boris Ostrovsky wrote
On 01/27/2016 01:11 PM, Andrew Cooper wrote:
c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM domains to
unconditionally intercept #UD exceptions. While cross-vendor migration is
cool as a demo, it is extremely niche.
Intercepting #UD allows userspace code in a multi-vcpu guest t
On Tue, Jan 26, 2016 at 05:48:34PM +0100, Fabio Fantoni wrote:
> I take a fast look to virgl 3d project even if I not tested it for now. It
> seems interesting for adding 2d and 3d hw acceleration support to virtual
> machines with a large hw (gpu) choice.
> I take a look also to intel gvt-g but it
On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
> I would like to hear the community's opinion on supporting more qdisk types in
> xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer supporting additional qdisk
> types
> in libxl over apps like xl or libvirt doing all the setup, producing a
On Sat, Jan 23, 2016 at 05:12:04PM +0100, Tommi Airikka wrote:
> Xen developers,
>
> After an upgrade of my Debian Jessie dom0 and domUs, my passthroughed
> NIC stopped working.
> This bug was probably introduced in Debian Jessie sometime
> between 2015-12-30 and 2016-01-08 as 2015-12-30 as 2015-1
Compiling qemu-xen at 2ce1d30 ("xenfb.c: avoid expensive loops when prod
<= out_cons") leads to this error with -O1:
xen.git/tools/qemu-xen-dir/hw/i386/intel_iommu.c: In function
‘vtd_context_device_invalidate’:
xen.git/tools/qemu-xen-dir/hw/i386/intel_iommu.c:911:46: error: ‘mask’ may be
used u
4.3-stable review patch. If anyone has any objections, please let me know.
--
From: David Vrabel
commit d8c98a1d1488747625ad6044d423406e17e99b7a upstream.
Adding the rtc platform device in non-privileged Xen PV guests causes
an IRQ conflict because these guests do not have leg
c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM domains to
unconditionally intercept #UD exceptions. While cross-vendor migration is
cool as a demo, it is extremely niche.
Intercepting #UD allows userspace code in a multi-vcpu guest to execute
arbitrary instructions in the x86 emu
Most updates to the exception bitmaps set or clear an individual bits.
However, entering or exiting emulated real mode unilaterally clobbers it,
leaving the exit code to recalculate what it should have been. This is error
prone, and indeed currently fails to recalculate the TRAP_no_device interce
This run is configured for baseline tests only.
flight 38708 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38708/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host
flight 79130 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79130/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail like 78683
Tests which did not succeed,
On Wed, Jan 13, 2016 at 02:59:09PM +, Stefano Stabellini wrote:
> On Xen MSIs can be remapped into pirqs, which are a type of event
> channels. It's mostly for the benefit of PCI passthrough devices, to
> avoid the overhead of interacting with the emulated lapic.
>
> However remapping interrup
On Tue, Jan 12, 2016 at 12:05:48PM +, Wei Liu wrote:
> Drop xen-users@, CC xen-devel@ and blk maintainers, change title.
>
What is the MTU you are using?
How do you mount the disk?
> On Mon, Jan 11, 2016 at 03:08:24PM +0100, Kojedzinszky Richárd wrote:
> > Dear all,
> >
> > We are facing a
xs_perm_to_string takes a size_t which isn't defined by anything
pulled in directly by this header.
Given the other headers xenstore_lib.h pulls in this looks to be an
oversight rather than a deliberate policy.
Signed-off-by: Ian Campbell
---
tools/xenstore/include/xenstore_lib.h | 1 +
1 file
On Sat, Nov 28, 2015 at 04:44:58PM -0500, Don Slutz wrote:
> From: Don Slutz
>
> This allows use of QEMU's VMware emulated video card
>
> NOTE: vga=vmware is not supported by device_model_version=qemu-xen-traditional
>
> Signed-off-by: Don Slutz
> CC: Don Slutz
> Acked-by: Ian Campbell
Revi
Hi everyone,
we are rebooting a number of Xen Project services in the next few days to
upgrade operating systems. This means that a few services may be temporarily
unavailable. The following websites are affected and will be done during the
times below. If you notice any issues after the reboot
On Wed, 2016-01-27 at 18:20 +0200, Pavlo Suikov wrote:
> Hi Ian,
Please don't top post and please use plain text emails, not html.
> I'll try to make clear domain restart thing first. Currently there are
> only device entries in domain config for frontends with backend paths in
> them, e.g.:
>
>
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> When MADT is parsed, print GIC information to make the boot log look
> pretty.
>
> Signed-off-by: Hanjun Guo
> Signed-off-by: Tomasz Nowicki
> Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
> V4: use PRIx64 ins
Hi Ian,
I'll try to make clear domain restart thing first. Currently there are only
device entries in domain config for frontends with backend paths in them,
e.g.:
FrontendDomain.cfg:
vdevice = [ 'backend=BackendDomain,devid=0,device=/dev/device' ]
it is parsed only on frontend domain start, and
On 1/27/2016 11:58 PM, Jan Beulich wrote:
On 27.01.16 at 16:23, wrote:
On 1/27/2016 11:12 PM, Jan Beulich wrote:
On 27.01.16 at 15:56, wrote:
On 1/27/2016 10:32 PM, Jan Beulich wrote:
On 27.01.16 at 15:13, wrote:
About the truncation issue:
I do not quite follow. Will this hurt
On 01/27/2016 10:29 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Jan 27, 2016 at 10:17:56AM -0500, Boris Ostrovsky wrote:
On 01/27/2016 10:09 AM, David Vrabel wrote:
On 27/01/16 15:06, Boris Ostrovsky wrote:
On 01/27/2016 09:50 AM, David Vrabel wrote:
On 27/01/16 14:42, Konrad Rzeszutek Wilk wrot
On Wed, 2016-01-27 at 16:01 +, George Dunlap wrote:
> On 27/01/16 15:45, Ian Campbell wrote:
> > For most patch series setting up a GH account and pushing the changes to it
> > etc is pure overhead (or at least optional), there is no need to encourage
> > it for most series, nor even necessaril
On Wed, Jan 27, 2016 at 02:50:36PM +, David Vrabel wrote:
> Surely the interesting comparison here is how is (early) microcode
> loading disabled in KVM guests?
It isn't - kvm simply ignores the write to the microcode application
MSRs MSR_AMD64_PATCH_LOADER and MSR_IA32_UCODE_REV, respectively
On Wed, Jan 27, 2016 at 03:53:38PM +, George Dunlap wrote:
> On 27/01/16 15:27, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 27, 2016 at 03:10:01PM +, George Dunlap wrote:
> >> On 27/01/16 14:33, Konrad Rzeszutek Wilk wrote:
> >>> On Xen - the schedule() would go HLT.. and then later be wok
>>> On 27.01.16 at 16:23, wrote:
>
> On 1/27/2016 11:12 PM, Jan Beulich wrote:
> On 27.01.16 at 15:56, wrote:
>>> On 1/27/2016 10:32 PM, Jan Beulich wrote:
>>> On 27.01.16 at 15:13, wrote:
> About the truncation issue:
> I do not quite follow. Will this hurt if the value c
On Wed, Jan 27, 2016 at 10:27:01AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 27, 2016 at 03:10:01PM +, George Dunlap wrote:
> > On 27/01/16 14:33, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Jan 26, 2016 at 11:21:36AM +, George Dunlap wrote:
> > >> On 22/01/16 16:54, Elena Ufimtseva
Andrew Cooper writes ("Re: [Xen-devel] [PATCH v9 02/25] docs/libxl: Introduce
COLO_CONTEXT to support migration v2 colo streams"):
> On 27/01/16 15:28, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 27, 2016 at 03:15:47PM +, Andrew Cooper wrote:
> >> Mandatory records may not be ignored, and con
On 27/01/16 15:45, Ian Campbell wrote:
> On Wed, 2016-01-27 at 15:18 +, Lars Kurth wrote:
>>> Doug says that you can mark a repo as a 'mirror', which will prevent
>>> people from being able to send pull requests to it; so I think my
>>> technical objection has been answered.
>>>
>>> I think the
flight 79108 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79108/
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. 78610
build-i386-rumpuserx
On 27/01/16 15:27, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 27, 2016 at 03:10:01PM +, George Dunlap wrote:
>> On 27/01/16 14:33, Konrad Rzeszutek Wilk wrote:
>>> On Xen - the schedule() would go HLT.. and then later be woken up by the
>>> VIRQ_TIMER. And since the two applications were on sep
On Wed, 2016-01-27 at 15:18 +, Lars Kurth wrote:
> > Doug says that you can mark a repo as a 'mirror', which will prevent
> > people from being able to send pull requests to it; so I think my
> > technical objection has been answered.
> >
> > I think the idea is still only half-baked though, a
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set, the
> former signals to the OS that the hardware is PSCI compliant. The latter
> selects the appropriate conduit for PSCI calls by toggling between
> Hypervisor Calls
On Wed, Jan 27, 2016 at 03:10:01PM +, George Dunlap wrote:
> On 27/01/16 14:33, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jan 26, 2016 at 11:21:36AM +, George Dunlap wrote:
> >> On 22/01/16 16:54, Elena Ufimtseva wrote:
> >>> Hello all!
> >>>
> >>> Dario, Gerorge or anyone else, your help w
On 1/27/2016 11:12 PM, Jan Beulich wrote:
On 27.01.16 at 15:56, wrote:
On 1/27/2016 10:32 PM, Jan Beulich wrote:
On 27.01.16 at 15:13, wrote:
About the truncation issue:
I do not quite follow. Will this hurt if the value configured does
not exceed 4G? What about a type cast?
A typec
On 27/01/16 15:28, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 27, 2016 at 03:15:47PM +, Andrew Cooper wrote:
>> On 27/01/16 15:11, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Jan 27, 2016 at 11:00:24AM +, Andrew Cooper wrote:
On 27/01/16 06:47, Wen Congyang wrote:
> On 01/27/2016 04:4
On Wed, Jan 27, 2016 at 10:17:56AM -0500, Boris Ostrovsky wrote:
> On 01/27/2016 10:09 AM, David Vrabel wrote:
> >On 27/01/16 15:06, Boris Ostrovsky wrote:
> >>On 01/27/2016 09:50 AM, David Vrabel wrote:
> >>>On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 26, 2016 at 08:54:56PM -
On Wed, Jan 27, 2016 at 03:15:47PM +, Andrew Cooper wrote:
> On 27/01/16 15:11, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 27, 2016 at 11:00:24AM +, Andrew Cooper wrote:
> >> On 27/01/16 06:47, Wen Congyang wrote:
> >>> On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, D
On 1/27/16 9:24 AM, Ian Campbell wrote:
> On Wed, 2016-01-27 at 09:11 -0600, Doug Goldstein wrote:
>> On 1/27/16 9:05 AM, Ian Campbell wrote:
>>> On Wed, 2016-01-27 at 07:44 -0700, Jan Beulich wrote:
>>> On 27.01.16 at 15:30, wrote:
> On 1/25/16 5:27 AM, Ian Campbell wrote:
>> On Wed,
On Wed, 2016-01-27 at 09:11 -0600, Doug Goldstein wrote:
> On 1/27/16 9:05 AM, Ian Campbell wrote:
> > On Wed, 2016-01-27 at 07:44 -0700, Jan Beulich wrote:
> > > > > > On 27.01.16 at 15:30, wrote:
> > > > On 1/25/16 5:27 AM, Ian Campbell wrote:
> > > > > On Wed, 2016-01-20 at 15:47 -0600, Doug Go
>>> On 27.01.16 at 15:51, wrote:
> On 27/01/16 14:40, Jan Beulich wrote:
>>
>> int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn,
>> - p2m_access_t access)
>> + unsigned int order, p2m_access_t access)
>> {
>> -
On 27/01/16 15:06, Boris Ostrovsky wrote:
> On 01/27/2016 09:50 AM, David Vrabel wrote:
>> On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
> On Tue, Jan 26, 2016 at 4
Sorry, I have been a little bit unresponsive. Things were a little hectic
in the last 2 weeks.
On 27/01/2016 11:21, "George Dunlap" wrote:
>
>> FWIW, I am +1 for setting up infrastructure like this, but lets do it
>> properly.
>>
>> Lars: Thoughts?
I don't mind if we had an official github mi
On 27/01/16 14:33, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 26, 2016 at 11:21:36AM +, George Dunlap wrote:
>> On 22/01/16 16:54, Elena Ufimtseva wrote:
>>> Hello all!
>>>
>>> Dario, Gerorge or anyone else, your help will be appreciated.
>>>
>>> Let me put some intro to our findings. I may fo
On 01/27/2016 10:09 AM, David Vrabel wrote:
On 27/01/16 15:06, Boris Ostrovsky wrote:
On 01/27/2016 09:50 AM, David Vrabel wrote:
On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wr
On 27/01/16 15:11, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 27, 2016 at 11:00:24AM +, Andrew Cooper wrote:
>> On 27/01/16 06:47, Wen Congyang wrote:
>>> On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote:
> It is the nego
On Wed, Jan 27, 2016 at 11:00:24AM +, Andrew Cooper wrote:
> On 27/01/16 06:47, Wen Congyang wrote:
> > On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote:
> >>> It is the negotiation record for COLO.
> >>> Primary->Secondary:
On 1/27/16 9:05 AM, Ian Campbell wrote:
> On Wed, 2016-01-27 at 07:44 -0700, Jan Beulich wrote:
> On 27.01.16 at 15:30, wrote:
>>> On 1/25/16 5:27 AM, Ian Campbell wrote:
On Wed, 2016-01-20 at 15:47 -0600, Doug Goldstein wrote:
> @@ -52,7 +52,7 @@ ALL_OBJS := $(TARGET_SUBARCH)/head.o
>>> On 27.01.16 at 15:56, wrote:
> On 1/27/2016 10:32 PM, Jan Beulich wrote:
> On 27.01.16 at 15:13, wrote:
>>> About the truncation issue:
>>> I do not quite follow. Will this hurt if the value configured does
>>> not exceed 4G? What about a type cast?
>>
>> A typecast would not alter be
On 1/27/2016 10:32 PM, Jan Beulich wrote:
On 27.01.16 at 15:13, wrote:
About the default value:
You are right. :) For XenGT, MAX_NR_IO_RANGES may only work under
limited conditions. Having it default to zero means XenGT users must
manually configure this option. Since we have plans to pus
On Wed, 2016-01-27 at 07:44 -0700, Jan Beulich wrote:
> > > > On 27.01.16 at 15:30, wrote:
> > On 1/25/16 5:27 AM, Ian Campbell wrote:
> > > On Wed, 2016-01-20 at 15:47 -0600, Doug Goldstein wrote:
> > > > @@ -52,7 +52,7 @@ ALL_OBJS := $(TARGET_SUBARCH)/head.o $(ALL_OBJS)
> > > >
> > > > $(TARG
On 01/27/2016 09:50 AM, David Vrabel wrote:
On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez
wrote:
You go:
hvmlite_star
Processing commands for x...@bugs.xenproject.org:
> close 34
Closing bug #34
> thanks
Finished processing.
Modified/created Bugs:
- 34: http://bugs.xenproject.org/xen/bug/34
---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on
reporting bugs
Peter Zijlstra wrote:
> +==
> +DISCLAIMER
> +==
> +
> +This document is not a specification; it is intentionally (for the sake of
> +brevity) and unintentionally (due to being human) incomplete. This document
> is
> +meant as a guide to using the various memory barriers provided
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> acpi_boot_table_init() will be called in start_xen to get the RSDP and
> all the table pointers. With this patch, we can get ACPI boot-time
> tables from firmware on ARM64.
>
> Signed-off-by: Naresh Bhat
> Signed-off-by: Parth Di
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> If ACPI is initialized after the boot allocator has ended(the system
> state is not early boot), assert happens in acpi_os_zalloc_memory and
> acpi_boot_table_init will fail. So it needs to move end_boot_allocator
> after acpi_boot
On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
> On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
> >
> > On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez
> wrote:
> > > You go:
> > >
> > > hvmlite_start_xen() -->
> > > HVM stub
> > > startup_64() | (start
On 27/01/16 14:40, Jan Beulich wrote:
>
> int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn,
> - p2m_access_t access)
> + unsigned int order, p2m_access_t access)
> {
> -return set_typed_p2m_entry(d, gfn, mfn,
On Wed, Jan 27, 2016 at 03:16:59AM -0700, Jan Beulich wrote:
> >>> On 26.01.16 at 20:32, wrote:
> > On Tue, Jan 26, 2016 at 09:34:13AM -0700, Jan Beulich wrote:
> >> >>> On 26.01.16 at 16:57, wrote:
> >> > On 01/26/16 08:37, Jan Beulich wrote:
> >> >> >>> On 26.01.16 at 15:44, wrote:
> >> >> >>
On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
>> On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
>>>
>>> On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez
>> wrote:
You go:
hvmlite_start_xen() -->
>>> On 27.01.16 at 15:30, wrote:
> On 1/25/16 5:27 AM, Ian Campbell wrote:
>> On Wed, 2016-01-20 at 15:47 -0600, Doug Goldstein wrote:
>>> @@ -52,7 +52,7 @@ ALL_OBJS := $(TARGET_SUBARCH)/head.o $(ALL_OBJS)
>>>
>>> $(TARGET): $(TARGET)-syms $(TARGET).axf
>>> $(OBJCOPY) -O binary -S $< $@
>>>
Processing commands for x...@bugs.xenproject.org:
> graft 34 ^
Graft `<1448998075-23878-1-git-send-email-car...@cardoe.com>' onto #34
> close it
Command failed: No previous bug found at
/srv/xen-devel-bugs/lib/emesinae/control.pl line 273, line 2.
Stop processing here.
Modified/created Bugs:
-
1 - 100 of 183 matches
Mail list logo
