flight 61316 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail in 61096 REGR. vs. 60666
build-i386-xsm
flight 61350 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61350/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 3 host-install(3) broken REGR. vs. 61304
buil
Previous the message was like:
SAVE:
xc: detail: 32 bits, 3 levels
xc: detail: max_pfn 0xf, p2m_frames 1024
xc: detail: max_mfn 0x13
RESTORE:
xc: detail: max_mfn 0x13
xc: detail: 32 bits, 3 levels
xc: detail: Expanded p2m from 0 to 0xf
It's not immediately clear that the last lin
The prefix "Memory" is confusing because the numbers shown after that
are referring to frames. They have no bearing on how many pages a domain
actually owns or how many actual pages are processed.
Signed-off-by: Wei Liu
---
tools/libxc/xc_sr_save.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
---
tools/libxc/xc_sr_restore_x86_pv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxc/xc_sr_restore_x86_pv.c
b/tools/libxc/xc_sr_restore_x86_pv.c
index c65a2f1..bc604b3 100644
--- a/tools/libxc/xc_sr_restore_x86_
Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
---
tools/libxc/xc_sr_restore.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index 924dd55..f48e7fc 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -18
The original implementation of populate_pfns didn't consider the same
pfn can be present multiple times in the array. The mechanism to prevent
populating the same pfn multiple times only worked if the recurring pfn
appeared in different batches.
This bug is discovered by Linux 4.1 32 bit kernel sa
Wei Liu (5):
libxc: clearer migration v2 debug message
libxc: migration v2 prefix Memory -> Frames
libxc: fix indentation
libxc: don't populate same pfn more than once in populate_pfns
libxc: add assertion to avoid setting same bit more than once
tools/libxc/xc_sr_restore.c| 7 +
On 04/09/15 14:55, Jan Beulich wrote:
On 04.09.15 at 15:51, wrote:
El 04/09/15 a les 14.25, Wei Liu ha escrit:
On Fri, Sep 04, 2015 at 02:08:50PM +0200, Roger Pau Monne wrote:
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 045f6ff..fe9504f 100644
--- a/xen/arch/x86/domain.c
flight 61309 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61309/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 19 guest-start/debianhvm.repeat fail
REGR. vs. 60723
R
Hi Konrad,
On 04/09/2015 18:32, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 04, 2015 at 05:15:13PM +0100, Julien Grall wrote:
On 04/09/15 16:41, Konrad Rzeszutek Wilk wrote:
Maybe we could fall back to the previous plan of modifying xen-blkfront
for the moment?
Which afaic need to be reposted?
On 04/09/15 19:32, Wei Liu wrote:
The original implementation didn't consider there can be same gpfns
present multiple times in the passed in array. The mechanism to prevent
populating same gpfn multiple times only works if the same gpfn appear
in different batch.
This bug is discovered by s
On Fri, Sep 4, 2015 at 2:17 AM, Jan Beulich wrote:
> >>> On 03.09.15 at 21:39, wrote:
> > So this change in 4.6 prevents me from passing through devices that have
> > worked previously with VT-d:
> >
> > (XEN) [VT-D] cannot assign :00:1a.0 with shared RMRR at ae8a9000 for
> > Dom30.
> > (XEN
On Fri, Sep 04, 2015 at 09:40:55PM +0100, Andrew Cooper wrote:
> On 04/09/15 19:32, Wei Liu wrote:
> >The prefix "Memory" is confusing because the numbers shown after that
> >are referring to P2M entries. They have no bearing on how many pages a
> >domain actually owns or how many actual pages are
On Fri, Sep 04, 2015 at 09:43:16PM +0100, Andrew Cooper wrote:
> On 04/09/15 19:32, Wei Liu wrote:
> >Signed-off-by: Wei Liu
>
> This surely isn't bisectable with patch 5? The change is fine (so
> Reviewed-by: Andrew Cooper ), provided you either
> reverse patches 4 and 5, or fold them together.
On 04/09/15 19:32, Wei Liu wrote:
Signed-off-by: Wei Liu
This surely isn't bisectable with patch 5? The change is fine (so
Reviewed-by: Andrew Cooper ), provided you
either reverse patches 4 and 5, or fold them together.
~Andrew
___
Xen-devel m
On 04/09/15 19:32, Wei Liu wrote:
Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 04/09/15 19:32, Wei Liu wrote:
The prefix "Memory" is confusing because the numbers shown after that
are referring to P2M entries. They have no bearing on how many pages a
domain actually owns or how many actual pages are processed.
Signed-off-by: Wei Liu
---
tools/libxc/xc_sr_save.c | 2 +
On 04/09/15 19:32, Wei Liu wrote:
Previous the message was like:
SAVE:
xc: detail: 32 bits, 3 levels
xc: detail: max_pfn 0xf, p2m_frames 1024
xc: detail: max_mfn 0x13
RESTORE:
xc: detail: max_mfn 0x13
xc: detail: 32 bits, 3 levels
xc: detail: Expanded p2m from 0 to 0xf
It's not
On 04/09/15 20:46, Wei Liu wrote:
When I looked at write_batch() I found some snippets that I thought to
be wrong. But I didn't what to make the judgement when I didn't have a
clear head.
write_batch() is a complicated function but it can't usefully be split any
further. I would be happy to e
On Fri, Sep 04, 2015 at 07:39:27PM +0100, Andrew Cooper wrote:
>
>
> On 04/09/15 12:35, Wei Liu wrote:
> >On Fri, Sep 04, 2015 at 10:35:52AM +0100, Andrew Cooper wrote:
> >>On 04/09/15 09:28, Jan Beulich wrote:
> >>On 04.09.15 at 05:38, wrote:
> On 09/04/2015 02:40 AM, Wei Liu wrote:
> >
Hello,
I am a student at FIU working on a school project so I am a not very
experienced. Right now I am trying to use the Xen API code I found at
https://github.com/xenserver/xenadmin to Snapshot a VM. The project I have
so far uses the XenAPI.VM functions and I have been successful in starting
an
On 04/09/15 12:35, Wei Liu wrote:
On Fri, Sep 04, 2015 at 10:35:52AM +0100, Andrew Cooper wrote:
On 04/09/15 09:28, Jan Beulich wrote:
On 04.09.15 at 05:38, wrote:
On 09/04/2015 02:40 AM, Wei Liu wrote:
This issue is exposed by the introduction of migration v2. The symptom is that
a guest
Wei Liu (5):
libxc: clearer migration v2 debug message
libxc: migration v2 prefix Memory -> Memory (P2M)
libxc: fix indentation
libxc: add assertion to avoid setting same bit more than once
libxc: de-duplicate gpfns in populate_pfns
tools/libxc/xc_sr_restore.c| 20 ++
Previous the message was like:
SAVE:
xc: detail: 32 bits, 3 levels
xc: detail: max_pfn 0xf, p2m_frames 1024
xc: detail: max_mfn 0x13
RESTORE:
xc: detail: max_mfn 0x13
xc: detail: 32 bits, 3 levels
xc: detail: Expanded p2m from 0 to 0xf
It's not immediately clear that the last lin
Signed-off-by: Wei Liu
---
tools/libxc/xc_sr_restore_x86_pv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxc/xc_sr_restore_x86_pv.c
b/tools/libxc/xc_sr_restore_x86_pv.c
index c65a2f1..bc604b3 100644
--- a/tools/libxc/xc_sr_restore_x86_pv.c
+++ b/tools/libxc/xc_sr
The prefix "Memory" is confusing because the numbers shown after that
are referring to P2M entries. They have no bearing on how many pages a
domain actually owns or how many actual pages are processed.
Signed-off-by: Wei Liu
---
tools/libxc/xc_sr_save.c | 2 +-
1 file changed, 1 insertion(+), 1
The original implementation didn't consider there can be same gpfns
present multiple times in the passed in array. The mechanism to prevent
populating same gpfn multiple times only works if the same gpfn appear
in different batch.
This bug is discovered by save / restore Linux 4.1 32 bit kernel, w
Signed-off-by: Wei Liu
---
tools/libxc/xc_sr_restore.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index df885b6..adb48da 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -181,6 +181,7 @@ static int pfn
flight 61306 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61306/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs. 61059
Regressions which a
On Fri, Sep 04, 2015 at 05:15:13PM +0100, Julien Grall wrote:
> On 04/09/15 16:41, Konrad Rzeszutek Wilk wrote:
> >> Maybe we could fall back to the previous plan of modifying xen-blkfront
> >> for the moment?
> >
> > Which afaic need to be reposted?
>
> Right. Although I didn't see any comment o
On Fri, Sep 04, 2015 at 02:51:10PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 04/09/15 11:08, Roger Pau Monne wrote:
> > Request allocation has been moved to connect_ring, which is called every
> > time blkback connects to the frontend (this can happen multiple times during
> > a blkback instan
Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
---
xen/arch/x86/hvm/hvm.c | 36 ++--
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 6f6cadc..ff94a9c 100644
--- a/xen/arch/x86/hvm/hvm.c
Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
---
xen/arch/x86/domain.c | 27 ---
xen/arch/x86/hvm/hvm.c| 24 +++-
xen/arch/x86/hvm/vmx/vmcs.c | 2 +-
xen/arch/x86/hvm/vmx/vmx.c| 19 +++
xen/include/asm-
32-bit PVH-classic support
Changes in v5:
* Added patch 2 that prevents a 32-bit PVH guest from turning off PAE
Changes in v4:
* Add xenpmu_op hypercall to pvh_hypercall32_table[] (patch 3)
* Adjust 'is_pvh_domain(currd)' test to match a similar test further in the
routine (patch 3)
Changes in
Add is_pvh_32bit_domain() macro and use it alongside is_pv_32bit_domain() where
necessary.
Since PVH guests cannot change execution mode, has_32bit_shinfo is a good
indicator of whether the guest is PVH and 32-bit.
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/domain.c| 6 +++---
xen/
On Fri, 2015-09-04 at 17:38 +0100, Ian Campbell wrote:
> On Fri, 2015-09-04 at 17:04 +0100, Ian Campbell wrote:
> > On Tue, 2015-07-07 at 17:26 +0200, Epiontis IT wrote:
> > > Hello,
> > >
> > > I already posted on the xen-users list and Ian told me to post a bug
> > > report here. We have the fo
.. since we only support 32-bit PV(H) guests in PAE mode.
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/hvm/hvm.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 90ba676..6f6cadc 100644
--- a/xen/arch/x
Signed-off-by: Boris Ostrovsky
Acked-by: Ian Campbell
---
tools/libxc/xc_dom_x86.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 3d40fa4..05fb0ce 100644
--- a/tools/libxc/xc_dom_x86
On Fri, 2015-09-04 at 17:04 +0100, Ian Campbell wrote:
> On Tue, 2015-07-07 at 17:26 +0200, Epiontis IT wrote:
> > Hello,
> >
> > I already posted on the xen-users list and Ian told me to post a bug
> > report here. We have the following problem:
> >
> > When I start a migration with "xl migrate
On Fri, 2015-09-04 at 17:47 +0200, Roger Pau Monné wrote:
> El 04/09/15 a les 17.21, Jan Beulich ha escrit:
> > > > > AP startup
> > > > > > > > ==
> > > > > > > >
> > > > > > > > AP startup is performed using hypercalls. The following
> > > > > > > > VCPU operations
> > > > > > > > are u
On Fri, 2015-09-04 at 10:01 -0600, Jan Beulich wrote:
> >
> > > > On 04.09.15 at 17:26, wrote:
> > On Fri, 2015-09-04 at 09:21 -0600, Jan Beulich wrote:
> > > > > > On 04.09.15 at 16:31, wrote:
> > > > El 04/09/15 a les 16.08, Jan Beulich ha escrit:
> > > > > > > > On 04.09.15 at 14:11, wrote:
El 04/09/15 a les 18.03, Jan Beulich ha escrit:
On 04.09.15 at 17:47, wrote:
>> VCPUOP_initialize was never available to HVM guests, so I don't think
>> changing the argument is a problem. However, I understand that for the
>> sake of clarity overloading an hypercall this way is not the best
On 04/09/15 16:41, Konrad Rzeszutek Wilk wrote:
>> Maybe we could fall back to the previous plan of modifying xen-blkfront
>> for the moment?
>
> Which afaic need to be reposted?
Right. Although I didn't see any comment on the patch. All the comments
was about the problem. Does it mean that you a
On Tue, 2015-07-07 at 17:26 +0200, Epiontis IT wrote:
> Hello,
>
> I already posted on the xen-users list and Ian told me to post a bug
> report here. We have the following problem:
>
> When I start a migration with "xl migrate " the
> destination machine sets up a vm "--incoming" and seems to
>>> On 04.09.15 at 17:47, wrote:
> VCPUOP_initialize was never available to HVM guests, so I don't think
> changing the argument is a problem. However, I understand that for the
> sake of clarity overloading an hypercall this way is not the best
> practice. What about naming it VCPUOP_hvm_initiali
>>> On 04.09.15 at 17:26, wrote:
> On Fri, 2015-09-04 at 09:21 -0600, Jan Beulich wrote:
>> > > > On 04.09.15 at 16:31, wrote:
>> > El 04/09/15 a les 16.08, Jan Beulich ha escrit:
>> > > > > > On 04.09.15 at 14:11, wrote:
>> > > > AP startup
>> > > > ==
>> > > >
>> > > > AP startup is p
>>> On 25.08.15 at 03:57, wrote:
First of all - an empty Cc list on a patch is suspicious.
> @@ -198,6 +199,109 @@ void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci)
> xfree(dpci);
> }
>
> +/*
> + * This routine handles lowest-priority interrupts using vector-hashing
> + * mechanism. As a
El 04/09/15 a les 17.21, Jan Beulich ha escrit:
AP startup
>>> ==
>>>
>>> AP startup is performed using hypercalls. The following VCPU operations
>>> are used in order to bring up secondary vCPUs:
>>>
>>> * VCPUOP_initialise is used to set the initial sta
On 04/09/15 13:05, Juergen Gross wrote:
> Instead of using physical addresses for accounting of extra memory
> areas available for ballooning switch to pfns as this is much less
> error prone regarding partial pages.
Applied to for-linus-4.3, thanks.
David
___
On 04/09/15 13:18, Juergen Gross wrote:
> When a pv-domain (including dom0) is started it tries to size it's
> p2m list according to the maximum possible memory amount it ever can
> achieve. Limit the initial maximum memory size to the architectural
> limit of the hardware in order to avoid overflo
On Fri, 2015-09-04 at 09:21 -0600, Jan Beulich wrote:
> >
> > > > On 04.09.15 at 16:31, wrote:
> > El 04/09/15 a les 16.08, Jan Beulich ha escrit:
> > > > > > On 04.09.15 at 14:11, wrote:
> > > > The format of the structure passed in the %ebx register is the
> > > > following:
> > >
> > > Even
On Fri, Sep 04, 2015 at 03:04:18PM +0100, Stefano Stabellini wrote:
> On Thu, 27 Aug 2015, Julien Grall wrote:
> > On 21/08/15 18:10, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Aug 21, 2015 at 05:08:35PM +0100, David Vrabel wrote:
> > >> On 21/08/15 17:05, Konrad Rzeszutek Wilk wrote:
> > >>>
> > >
>>> On 04.09.15 at 16:22, wrote:
> Oh, in which case removing (from Xen) the recommendation to try noapic
> might be useful.
Hmm - so far I didn't the option was not working. I also don't
understand the reference to pv-ops kernels in the doc. Sadly it's
not clear where this comes from, since Ian
>>> On 04.09.15 at 16:13, wrote:
> On Fri, 2015-09-04 at 15:04 +0100, David Vrabel wrote:
>> On 04/09/15 14:38, Ian Campbell wrote:
>> > On Thu, 2015-08-13 at 00:59 +0200, Guido Günther wrote:
>> > > Package: xen-hypervisor-4.5-amd64
>> > > Severity: normal
>> > >
>> > > Hi,
>> > > when running x
>>> On 04.09.15 at 16:31, wrote:
> El 04/09/15 a les 16.08, Jan Beulich ha escrit:
> On 04.09.15 at 14:11, wrote:
>>> The format of the structure passed in the %ebx register is the following:
>>
>> Even if it may sound like splitting hair: Please use precise wording. It's
>> not the structur
>>> On 04.09.15 at 16:31, wrote:
> El 04/09/15 a les 16.08, Jan Beulich ha escrit:
> On 04.09.15 at 14:11, wrote:
>>> * tr: must be a 32-bit TSS (active) with a base of '0' and a limit of
>>> '0xFF'.
>>
>> Already on the previous version I asked about this strange 0xFF,
>> and I don't reca
>>> On 25.08.15 at 03:57, wrote:
> --- a/xen/include/asm-x86/apicdef.h
> +++ b/xen/include/asm-x86/apicdef.h
> @@ -124,6 +124,10 @@
>
> #define MAX_IO_APICS 128
>
> +#define APIC_SHORT_MASK 0xc
> +#define APIC_DEST_NOSHORT0x0
> +#define APIC_DEST_MASK
>>> On 25.08.15 at 03:57, wrote:
> --- a/xen/include/asm-x86/x86_64/system.h
> +++ b/xen/include/asm-x86/x86_64/system.h
> @@ -6,6 +6,34 @@
> (unsigned long)(n),sizeof(*(ptr
>
> /*
> + * Atomic 16 bytes compare and exchange. Compare OLD with MEM, if
> +
>>> On 25.08.15 at 03:57, wrote:
> This patch adds an API which is used to update the IRTE
> for posted-interrupt when guest changes MSI/MSI-X information.
>
> CC: Yang Zhang
> CC: Kevin Tian
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Andrew Cooper
> Signed-off-by: Feng Wu
> Acked-by: Kevin
On 04/09/15 15:53, Wei Liu wrote:
> On Fri, Sep 04, 2015 at 03:42:06PM +0100, David Vrabel wrote:
>> On 04/09/15 09:53, Ian Campbell wrote:
>>> On Fri, 2015-09-04 at 01:40 +0100, Wei Liu wrote:
Hi David
This issue is exposed by the introduction of migration v2. The symptom is
t
>>> On 25.08.15 at 03:57, wrote:
> Remove pointless casts.
Much appreciated, but ...
> @@ -281,11 +280,10 @@ static void dump_iommu_info(unsigned char key)
>
> printk(" %02x: %04x %x%x %x %x %x%x"
> "%x %02x\n", i,
> -
On Fri, Sep 04, 2015 at 03:42:06PM +0100, David Vrabel wrote:
> On 04/09/15 09:53, Ian Campbell wrote:
> > On Fri, 2015-09-04 at 01:40 +0100, Wei Liu wrote:
> >> Hi David
> >>
> >> This issue is exposed by the introduction of migration v2. The symptom is
> >> that
> >> a guest with 32 bit 4.1 kern
>>> On 25.08.15 at 03:57, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1701,8 +1701,36 @@ static void vmx_deliver_posted_intr(struct vcpu *v, u8
> vector)
> */
> pi_set_on(&v->arch.hvm_vmx.pi_desc);
> }
> -else if ( !pi_test_and_se
On Fri, 2015-09-04 at 14:22 +0100, Wei Liu wrote:
> On Wed, Sep 02, 2015 at 12:17:05PM +0100, Paul Durrant wrote:
> > netif.h contains a specification of the
> > XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL}
> > extra info messages require to manipulate a multicast filter list
> > maintained
> > by a back
>>> On 25.08.15 at 03:57, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
I can't seem to spot what this is needed for.
> @@ -951,6 +952,20 @@ void virtual_vmcs_vmwrite(void *vvmcs, u32
> vmcs
On Fri, 2015-09-04 at 14:19 +0100, Wei Liu wrote:
> On Fri, Sep 04, 2015 at 01:56:20PM +0100, Ian Campbell wrote:
> > On Fri, 2015-09-04 at 13:12 +0100, Wei Liu wrote:
> > >
> > > But this point is moot since I said in the other email I was happy
> > > with
> > > that one-liner applied today.
> >
On 04/09/15 09:53, Ian Campbell wrote:
> On Fri, 2015-09-04 at 01:40 +0100, Wei Liu wrote:
>> Hi David
>>
>> This issue is exposed by the introduction of migration v2. The symptom is
>> that
>> a guest with 32 bit 4.1 kernel can't be restored because it's asking for too
>> many pages.
>
> FWIW my
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 04 September 2015 15:42
> To: Wei Liu; Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Keir (Xen.org); Tim (Xen.org); Ian
> Jackson; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v2] public/io/netif.h: mov
On Wed, 2015-09-02 at 13:25 +0100, David Scott wrote:
> >
> > On 2 Sep 2015, at 11:57, Ian Campbell wrote:
> >
> > On Wed, 2015-09-02 at 11:04 +0100, David Scott wrote:
> > > From: David Scott
> > >
> > > Replace my sometimes unreliable address
> > > with
> > > my reliable permanent address.
On Wed, 2015-09-02 at 16:45 +0100, Julien Grall wrote:
> On 02/09/15 16:28, Ian Campbell wrote:
> > On Mon, 2015-08-31 at 15:20 +0100, Julien Grall wrote:
> > > Hi Vijay,
> > >
> > > On 31/08/2015 12:06, vijay.kil...@gmail.com wrote:
> > > > From: Vijaya Kumar K
> > > >
> > > > dt_for_each_irq_m
On Wed, 2015-09-02 at 15:31 +0100, Ian Campbell wrote:
> On Wed, 2015-09-02 at 09:22 -0500, Doug Goldstein wrote:
> > On 9/2/15 9:14 AM, Jan Beulich wrote:
> > > > > > On 02.09.15 at 15:34, wrote:
> > > > On Wed, 2015-09-02 at 07:14 -0600, Jan Beulich wrote:
> > > > > > > > On 02.09.15 at 15:09,
On Thu, 2015-09-03 at 19:27 +0100, Wei Liu wrote:
> Otherwise when building with 32bit compiler, we get:
>
> xen-access.c: In function 'xenaccess_init':
> xen-access.c:263:5: error: format '%llx' expects argument of type 'long
> long unsigned int', but argument 3 has type 'xen_pfn_t' [-Werror=for
On Fri, 2015-09-04 at 14:16 +0100, Wei Liu wrote:
> On Fri, Sep 04, 2015 at 01:57:00PM +0100, Julien Grall wrote:
> > The commit 88e3ed61642bb393458acc7a9bd2f96edc337190 "x86/NUMA: make
> > init_node_heap() respect Xen heap limit" breaks boot on the arm64 board
> > X-Gene.
> >
> > The xenheap bits
>>> On 25.08.15 at 03:57, wrote:
> @@ -121,11 +122,31 @@ static inline int pi_test_and_clear_on(struct pi_desc
> *pi_desc)
> return test_and_clear_bit(POSTED_INTR_ON, &pi_desc->control);
> }
>
> +static inline int pi_test_on(struct pi_desc *pi_desc)
> +{
> +return test_bit(POSTED_INTR
El 04/09/15 a les 16.08, Jan Beulich ha escrit:
On 04.09.15 at 14:11, wrote:
>> * cs: must be a 32-bit read/execute code segment with an offset of ‘0’
>>and a limit of ‘0x’. The selector value is unspecified.
>>
>> * ds, es: must be a 32-bit read/write data segment with an offse
>>> On 25.08.15 at 03:57, wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2079,6 +2079,9 @@ static int init_vtd_hw(void)
> disable_intremap(drhd->iommu);
> }
>
> +if ( !iommu_intremap )
> +iommu_intpost = 0;
>>> On 25.08.15 at 03:57, wrote:
> Extend struct pi_desc according to VT-d Posted-Interrupts Spec.
>
> CC: Kevin Tian
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Andrew Cooper
> Signed-off-by: Feng Wu
> Reviewed-by: Andrew Cooper
> Acked-by: Kevin Tian
> Reviewed-by: Konrad Rzeszutek Wilk
>
On 04/09/15 15:13, Ian Campbell wrote:
> On Fri, 2015-09-04 at 15:04 +0100, David Vrabel wrote:
>> On 04/09/15 14:38, Ian Campbell wrote:
>>> Control: tag -1 upstream
>>>
>>> Jan/Andy & David,
>>>
>>> Is there anything we can improve here on either the Xen or kernel side
>>> do
>>> you think?
>>>
>>> On 25.08.15 at 03:57, wrote:
> 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.
>
> Thi
>>> On 25.08.15 at 03:57, wrote:
> This patch adds cmpxchg16b support for x86-64, so software
> can perform 128-bit atomic write/read.
>
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Andrew Cooper
> Signed-off-by: Feng Wu
> ---
> v6:
> - Fix a typo
>
> v5:
> - Change back the parameters of __cmp
On Fri, 2015-09-04 at 15:04 +0100, David Vrabel wrote:
> On 04/09/15 14:38, Ian Campbell wrote:
> > Control: tag -1 upstream
> >
> > Jan/Andy & David,
> >
> > Is there anything we can improve here on either the Xen or kernel side
> > do
> > you think?
> >
> > On Thu, 2015-08-13 at 00:59 +0200,
El 04/09/15 a les 14.18, Juergen Gross ha escrit:
> When a pv-domain (including dom0) is started it tries to size it's
> p2m list according to the maximum possible memory amount it ever can
> achieve. Limit the initial maximum memory size to the architectural
> limit of the hardware in order to avo
El 04/09/15 a les 14.05, Juergen Gross ha escrit:
> Instead of using physical addresses for accounting of extra memory
> areas available for ballooning switch to pfns as this is much less
> error prone regarding partial pages.
>
> Reported-by: Roger Pau Monné
> Signed-off-by: Juergen Gross
Test
On Thu, 27 Aug 2015, Julien Grall wrote:
> On 21/08/15 18:10, Konrad Rzeszutek Wilk wrote:
> > On Fri, Aug 21, 2015 at 05:08:35PM +0100, David Vrabel wrote:
> >> On 21/08/15 17:05, Konrad Rzeszutek Wilk wrote:
> >>>
> >>> I have to concur with that. We can't mandate that ARM 64k page MUST use
> >>>
>>> On 04.09.15 at 14:11, wrote:
> * cs: must be a 32-bit read/execute code segment with an offset of ‘0’
>and a limit of ‘0x’. The selector value is unspecified.
>
> * ds, es: must be a 32-bit read/write data segment with an offset of
>‘0’ and a limit of ‘0x’. The selec
On 04/09/15 14:38, Ian Campbell wrote:
> Control: tag -1 upstream
>
> Jan/Andy & David,
>
> Is there anything we can improve here on either the Xen or kernel side do
> you think?
>
> On Thu, 2015-08-13 at 00:59 +0200, Guido Günther wrote:
>> Package: xen-hypervisor-4.5-amd64
>> Severity: normal
On Fri, Sep 04, 2015 at 03:51:17PM +0200, Roger Pau Monné wrote:
> El 04/09/15 a les 14.25, Wei Liu ha escrit:
> > On Fri, Sep 04, 2015 at 02:08:50PM +0200, Roger Pau Monne wrote:
> >> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> >> index 045f6ff..fe9504f 100644
> >> --- a/xen/arch/
>>> On 04.09.15 at 15:51, wrote:
> El 04/09/15 a les 14.25, Wei Liu ha escrit:
>> On Fri, Sep 04, 2015 at 02:08:50PM +0200, Roger Pau Monne wrote:
>>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
>>> index 045f6ff..fe9504f 100644
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86
On Fri, 2015-09-04 at 08:48 -0500, Doug Goldstein wrote:
> On 8/27/15 12:58 PM, Ian Jackson wrote:
> > Wei Liu writes ("[PATCH for 4.6] build: fix tarball stubdom build"):
> > > When we create a source code tarball, mini-os is extracted to
> > > extras/mini-os directory. When building a source code
Hi Roger,
On 04/09/15 11:08, Roger Pau Monne wrote:
> Request allocation has been moved to connect_ring, which is called every
> time blkback connects to the frontend (this can happen multiple times during
> a blkback instance life cycle). On the other hand, request freeing has not
> been moved, s
El 04/09/15 a les 14.25, Wei Liu ha escrit:
> On Fri, Sep 04, 2015 at 02:08:50PM +0200, Roger Pau Monne wrote:
>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
>> index 045f6ff..fe9504f 100644
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -555,6 +555,29 @@ int arc
On 8/27/15 12:58 PM, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for 4.6] build: fix tarball stubdom build"):
>> When we create a source code tarball, mini-os is extracted to
>> extras/mini-os directory. When building a source code tarball, we
>> shouldn't clone mini-os again.
>>
>> Only clone min
Use this in libxl_dm instead of hard-coding.
Signed-off-by: Vitaly Kuznetsov
Acked-by: Ian Campbell
---
Changes since v10:
- s,XC,LIBXL,g to meet the XC_DEVICE_MODEL_RESTORE_FILE ->
LIBXL_DEVICE_MODEL_RESTORE_FILE change.
---
tools/libxl/libxl_dm.c | 2 +-
tools/libxl/libxl_internal.h |
As a preparation before adding new restart type (soft reset) put all
restart types into an enum.
Signed-off-by: Vitaly Kuznetsov
Acked-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk
---
Changes since v10:
- None.
---
tools/libxl/xl.h | 6 ++
tools/libxl/xl_cmdimpl.c | 23
Add new soft_reset vector to domain2 class, add it to create_domain
in the default policy.
Signed-off-by: Vitaly Kuznetsov
Acked-by: Daniel De Graaf
---
Changes since v10:
- None.
---
tools/flask/policy/policy/modules/xen/xen.if | 2 +-
xen/xsm/flask/hooks.c| 3 +++
xen/
New domctl resets state for a domain allowing it to 'start over': register
vcpu_info, switch to FIFO ABI for event channels. Still active grants are
being logged to help debugging misbehaving backends.
Signed-off-by: Vitaly Kuznetsov
Acked-by: Jan Beulich
---
Changes since v10:
- return when evt
Introduce xc_domain_soft_reset() function supporting XEN_DOMCTL_soft_reset.
Signed-off-by: Vitaly Kuznetsov
Acked-by: Wei Liu
Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Ian Jackson
---
Changes since v10:
- None.
---
tools/libxc/include/xenctrl.h | 3 +++
tools/libxc/xc_domain.c | 9 ++
Log first 10 active grants for a domain. This function is going to be used
for soft reset, active grants on this path usually mean misbehaving backends
refusing to release their mappings on shutdown. We need that in addition to
the already existent 'g' keyhandler as such misbehaving backends can ca
This special type of shutdown is supposed to be used by PVHVM guests when
they want to perform some sort of kexec/kdump.
Signed-off-by: Vitaly Kuznetsov
Acked-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
---
Changes since v10:
- None
---
xen/common/shutdown.c | 6 ++
xen/includ
1 - 100 of 211 matches
Mail list logo
