>>> On 17.11.14 at 20:21, wrote:
> Okay, I did a bisection and was not able to correlate the above error
> message with the problem I'm seeing. Not saying it's not related, but I
> had plenty of successful test runs in the presence of that error.
>
> Took me about a week (sometimes it takes as
flight 31650 qemu-upstream-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31650/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken REG
>>> On 17.11.14 at 18:06, wrote:
> On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich wrote:
>
>> >>> On 12.11.14 at 16:48, wrote:
>> > On 12/11/14 15:31, Tamas K Lengyel wrote:
>> >> xen/include/public/domctl.h | 44 +--
>> >> xen/include/public/hvm/params.h | 2 +-
>> >> xen/include
>>> On 17.11.14 at 17:43, wrote:
> On 11/17/2014 06:37 PM, Jan Beulich wrote:
> On 12.11.14 at 16:48, wrote:
>>> On 12/11/14 15:31, Tamas K Lengyel wrote:
xen/include/public/domctl.h | 44 +--
xen/include/public/hvm/params.h | 2 +-
xen/include/public/mem_event.
On 11/14/2014 05:08 PM, Andrew Cooper wrote:
On 14/11/14 15:32, Juergen Gross wrote:
On 11/14/2014 03:59 PM, Andrew Cooper wrote:
On 14/11/14 14:14, Jürgen Groß wrote:
On 11/14/2014 02:56 PM, Andrew Cooper wrote:
On 14/11/14 12:53, Juergen Gross wrote:
On 11/14/2014 12:41 PM, Andrew Cooper w
flight 31647 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31647/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-armhf-armhf-xl
Currently libxl__domain_rename only update /local/domain//name,
still some places in xenstore are not updated, including:
/vm//name and /local/domain/0/backend///.../domain.
This patch updates /vm//name in xenstore, and removes the unusual
'domain' field under backend directory (the affected are b
On 2014/11/17 19:51, Jan Beulich wrote:
On 17.11.14 at 12:32, wrote:
On 2014/11/17 19:17, Jan Beulich wrote:
On 17.11.14 at 12:08, wrote:
On 2014/11/17 18:05, Jan Beulich wrote:
On 17.11.14 at 08:57, wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -698,10 +698,13 @@ struct
flight 31604 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31604/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3)broken REGR. vs. 31489
>>> On 11/17/2014 at 11:45 PM, in message
<21610.6141.943750.141...@mariner.uk.xensource.com>, Ian Jackson
wrote:
> Chunyan Liu writes ("[PATCH] fix rename: xenstore not fully updated"):
> > Currently libxl__domain_rename only update /local/domain//name,
> > still some places in xenstore are
>>> On 11/17/2014 at 11:53 PM, in message <1416239594.5466.23.ca...@citrix.com>,
Ian Campbell wrote:
> On Mon, 2014-11-17 at 15:45 +, Ian Jackson wrote:
> > > +/* update backend
> > > /local/domain/0/backend///.../domain */
> >
> > Um, what on earth creates that ?
> >
> > Worse,
flight 31641 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303
Regressions which are
Monday, November 17, 2014, 9:43:47 PM, you wrote:
> . snip..
>> > # cat /proc/interrupts |grep eth
>> > 36: 384183 0 xen-pirq-ioapic-level eth0
>> > 63: 1 0 xen-pirq-msi-x eth1
>> > 64: 24 661961 xen-pirq-msi-x eth1-rx-0
>> > 65:2
flight 31601 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31601/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31553 REGR.
vs. 30767
Tests which are f
. snip..
> > # cat /proc/interrupts |grep eth
> > 36: 384183 0 xen-pirq-ioapic-level eth0
> > 63: 1 0 xen-pirq-msi-x eth1
> > 64: 24 661961 xen-pirq-msi-x eth1-rx-0
> > 65:205 0 xen-pirq-msi-x eth1-rx-1
> > 66:
On 11/12/2014 07:03 AM, Ian Campbell wrote:
> On Mon, 2014-11-10 at 10:38 -0500, Zhigang Wang wrote:
>> OK. Let me try my best:
>>
> I'm confused by the description of what's going on, in particular the
> mixing of mem-max commands and target xenstore nodes (since the former
> doesn't r
Hi Jan,
On 11/11/2014 0:05, Jan Beulich wrote:
And these
[ 199.775209] pcieport :00:03.0: AER: Multiple Corrected error
received: id=0018
[ 199.775238] pcieport :00:03.0: PCIe Bus Error:
severity=Corrected, type=Data Link Layer, id=0018(Transmitter ID)
[ 199.7
Monday, November 17, 2014, 5:34:16 PM, you wrote:
> On Fri, Nov 14, 2014 at 11:09:58PM +0100, Sander Eikelenboom wrote:
>>
>> Friday, November 14, 2014, 9:25:13 PM, you wrote:
>>
>> > On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>> >>
>> >> Friday, November 14, 2014, 4:4
On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> Thank you for your answer.
>
> On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
> wrote:
> > Although it is possible that that patch is the cause of your problem,
> > unfortunately it is part of a significant rework of the GIC d
On 17/11/14 17:00, Tim Deegan wrote:
> At 16:40 + on 17 Nov (1416238835), Andrew Cooper wrote:
>> On 17/11/14 16:30, Tim Deegan wrote:
>>> At 16:24 + on 17 Nov (1416237888), Jan Beulich wrote:
>>> On 17.11.14 at 16:39, wrote:
> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cp
On 11/17/2014 11:59 AM, Andrew Cooper wrote:
On 17/11/14 16:58, Ian Campbell wrote:
On Mon, 2014-11-17 at 15:19 +, Andrew Cooper wrote:
c/s d1b93ea causes substantial functional regressions in pygrub's ability to
parse bootloader configuration files.
Please can you and Boris both provide e
On Mon, Nov 17, 2014 at 5:44 PM, Jan Beulich wrote:
> >>> On 12.11.14 at 16:31, wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
>
> Leaving aside the general reservation I just voiced in reply to 0/7, I
> wonder whether - considering that you mostly replace the code
> th
On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich wrote:
> >>> On 12.11.14 at 16:48, wrote:
> > On 12/11/14 15:31, Tamas K Lengyel wrote:
> >> xen/include/public/domctl.h | 44 +--
> >> xen/include/public/hvm/params.h | 2 +-
> >> xen/include/public/mem_event.h | 134 ---
> >>
Hi Stefano,
Thank you for your answer.
On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
wrote:
> Although it is possible that that patch is the cause of your problem,
> unfortunately it is part of a significant rework of the GIC driver in
> Xen and I am afraid that testing with only a portion
Monday, November 17, 2014, 5:34:16 PM, you wrote:
> On Fri, Nov 14, 2014 at 11:09:58PM +0100, Sander Eikelenboom wrote:
>>
>> Friday, November 14, 2014, 9:25:13 PM, you wrote:
>>
>> > On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>> >>
>> >> Friday, November 14, 2014, 4:4
At 16:40 + on 17 Nov (1416238835), Andrew Cooper wrote:
> On 17/11/14 16:30, Tim Deegan wrote:
> > At 16:24 + on 17 Nov (1416237888), Jan Beulich wrote:
> > On 17.11.14 at 16:39, wrote:
> >>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> If hardware
On 17/11/14 16:58, Ian Campbell wrote:
> On Mon, 2014-11-17 at 15:19 +, Andrew Cooper wrote:
>> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
>> parse bootloader configuration files.
> Please can you and Boris both provide examples of (ideally real-world)
> config
On Mon, 2014-11-17 at 15:19 +, Andrew Cooper wrote:
> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
> parse bootloader configuration files.
Please can you and Boris both provide examples of (ideally real-world)
configuration files which exhibit these failures as
On 17/11/14 16:41, Boris Ostrovsky wrote:
> On 11/17/2014 10:19 AM, Andrew Cooper wrote:
>> c/s d1b93ea causes substantial functional regressions in pygrub's
>> ability to
>> parse bootloader configuration files.
>>
>> c/s d1b93ea itself changed an an interface which previously used
>> exclusively
On 11/17/2014 06:37 PM, Jan Beulich wrote:
On 12.11.14 at 16:48, wrote:
>> On 12/11/14 15:31, Tamas K Lengyel wrote:
>>> xen/include/public/domctl.h | 44 +--
>>> xen/include/public/hvm/params.h | 2 +-
>>> xen/include/public/mem_event.h | 134 ---
>>> xen/include/pub
>>> On 12.11.14 at 16:31, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
Leaving aside the general reservation I just voiced in reply to 0/7, I
wonder whether - considering that you mostly replace the code
that gets changed in this file - it wouldn't be a nice opportunity to
Although it is possible that that patch is the cause of your problem,
unfortunately it is part of a significant rework of the GIC driver in
Xen and I am afraid that testing with only a portion of that patch
series might introduce other subtle bugs. For your reference the series
starts at commit 6f
On 17/11/14 16:30, Tim Deegan wrote:
> At 16:24 + on 17 Nov (1416237888), Jan Beulich wrote:
> On 17.11.14 at 16:39, wrote:
>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
If hardware support the pdpe1gb flag, expose it to guest by default.
Users do
On 11/17/2014 10:19 AM, Andrew Cooper wrote:
c/s d1b93ea causes substantial functional regressions in pygrub's ability to
parse bootloader configuration files.
c/s d1b93ea itself changed an an interface which previously used exclusively
integers, to using strings in the case of a grub configurat
>>> On 12.11.14 at 16:48, wrote:
> On 12/11/14 15:31, Tamas K Lengyel wrote:
>> xen/include/public/domctl.h | 44 +--
>> xen/include/public/hvm/params.h | 2 +-
>> xen/include/public/mem_event.h | 134 ---
>> xen/include/public/memory.h | 6 +-
>> xen/include/pub
On Fri, Nov 14, 2014 at 11:09:58PM +0100, Sander Eikelenboom wrote:
>
> Friday, November 14, 2014, 9:25:13 PM, you wrote:
>
> > On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
> >>
> >> Friday, November 14, 2014, 4:43:58 PM, you wrote:
> >>
> >> On 14.11.14 at 16:20, w
At 16:24 + on 17 Nov (1416237888), Jan Beulich wrote:
> >>> On 17.11.14 at 16:39, wrote:
> > Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> >> If hardware support the pdpe1gb flag, expose it to guest by default.
> >> Users don't have to use a 'cpuid= ' option in c
Hi all,
last week Ian Jackson nominated Konrad as Xen Project Hypervisor committer.
Our governance process requires a formal vote by existing committers to confirm
Konrad and for me to set up a voting form. Existing committers are: Keir
Fraser, Ian Campbell, Ian Jackson, Jan Beulich and Tim Dee
>>> On 17.11.14 at 16:39, wrote:
> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>> If hardware support the pdpe1gb flag, expose it to guest by default.
>> Users don't have to use a 'cpuid= ' option in config file to turn
>> it on.
>
> I don't understand what this fla
On Mon, 2014-11-17 at 15:45 +, Ian Jackson wrote:
> > +/* update backend /local/domain/0/backend///.../domain
> > */
>
> Um, what on earth creates that ?
>
> Worse, what reads it ?
>
> I think that putting this information in the backend directory is
> entirely wrong.
I concluded the s
Hi,
Issue occurs after the following commit:
commit 5495a512b63bad868c147198f7f049c2617d468c
Author: Stefano Stabellini
Date: Tue Jun 10 15:07:12 2014 +0100
xen/arm: support HW interrupts, do not request maintenance_interrupts
If the irq to be injected is an hardware irq (p->desc !=
Chunyan Liu writes ("[PATCH] fix rename: xenstore not fully updated"):
> Currently libxl__domain_rename only update /local/domain//name,
> still some places in xenstore are not updated, including:
> /vm//name and /local/domain/0/backend///.../domain.
Thanks.
...
> +/* update /vm//name */
> +
Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> If hardware support the pdpe1gb flag, expose it to guest by default.
> Users don't have to use a 'cpuid= ' option in config file to turn
> it on.
I don't understand what this flag does. I guess from the name it
turns on
flight 31634 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31634/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
test-armhf-armhf-xl
c/s d1b93ea causes substantial functional regressions in pygrub's ability to
parse bootloader configuration files.
c/s d1b93ea itself changed an an interface which previously used exclusively
integers, to using strings in the case of a grub configuration with explicit
default set, along with chang
On Mon, 17 Nov 2014, Stefan Bader wrote:
> On 17.11.2014 13:39, Ian Campbell wrote:
> > On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:
> >> Hi,
> >>
> >>
> >> The wiki page is ready. I am not sure whether I am using the correct
> >> format or not. Please let me know if any changes are need. Tha
Well, Allen (the original VTd maintainer and the author of the IGD quirk code)
agrees that the original IGD quirk timeout code just used the VTd timeout as a
convenience. He's the one who identified 670 msec as the theoretical max
latency for IGD access but, due to certification issues, suggest
>>> On 17.11.14 at 15:51, wrote:
> My primary goal is to decouple the IGD quirk code from the VTd timeout value,
> the two are unrelated and shouldn't be using the same define. In the process
> we can clean up the IGD code so that, if a user wants, the user can specify a
> more appropriate tim
My primary goal is to decouple the IGD quirk code from the VTd timeout value,
the two are unrelated and shouldn't be using the same define. In the process
we can clean up the IGD code so that, if a user wants, the user can specify a
more appropriate timeout value for the quirk code. There's no
On Mon, 2014-11-17 at 15:44 +0100, Stefan Bader wrote:
> So far it seems like the two things missing would be the patch to qemu
> and starting an instance of it for dom0 (maybe), right?
Yes to both AFAICT.
Ian.
___
Xen-devel mailing list
Xen-devel@li
On 17.11.2014 13:39, Ian Campbell wrote:
> On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:
>> Hi,
>>
>>
>> The wiki page is ready. I am not sure whether I am using the correct
>> format or not. Please let me know if any changes are need. Thanks,
>>
>>
>> http://wiki.xenproject.org/wiki/Xen_via_l
On 17/11/14 14:11, Stefano Stabellini wrote:
> Hi all,
> I am writing this email to ask for your advice.
>
> On architectures where dma addresses are different from physical
> addresses, it can be difficult to retrieve the physical address of a
> page from its dma address.
>
> Specifically this i
>>> On 17.11.14 at 15:27, wrote:
> I'm a big believer in backward compatibility, especially in not doing things
> that change current defined behavior. The current `snb_igd_quirk' flag
> enables the quirk code with a 1sec timeout. Even though that value is
> excessive silently changing the me
I'm a big believer in backward compatibility, especially in not doing things
that change current defined behavior. The current `snb_igd_quirk' flag enables
the quirk code with a 1sec timeout. Even though that value is excessive
silently changing the meaning of the parameter just seems wrong.
Hi all,
I am writing this email to ask for your advice.
On architectures where dma addresses are different from physical
addresses, it can be difficult to retrieve the physical address of a
page from its dma address.
Specifically this is the case for Xen on arm and arm64 but I think that
other ar
>>> On 17.11.14 at 14:49, wrote:
> On Mon, Nov 17, 2014 at 01:35:17PM +, Jan Beulich wrote:
>> >>> On 14.11.14 at 16:32, wrote:
>> > On Fri, Nov 14, 2014 at 12:37:30PM +, Jan Beulich wrote:
>> >> The specification is kind of vague under what conditions
>> >> ExitBootServices() may legitim
On Mon, Nov 17, 2014 at 11:17:45AM +, Stefano Stabellini wrote:
> On Sun, 16 Nov 2014, Li, Liang Z wrote:
> > > > > Konrad,
> > > > > this is another bug fix for QEMU: pci hotplug doesn't work when
> > > > > xen_platform_pci=0 without this.
> > > >
> > > > Yes.
> > > > >
> > > > >I think we sho
On Mon, Nov 17, 2014 at 01:35:17PM +, Jan Beulich wrote:
> >>> On 14.11.14 at 16:32, wrote:
> > On Fri, Nov 14, 2014 at 12:37:30PM +, Jan Beulich wrote:
> >> The specification is kind of vague under what conditions
> >> ExitBootServices() may legitimately fail, requiring the OS loader to
>
>>> On 17.11.14 at 14:32, wrote:
> Hmm, good ideas. How about I change the `snb_igd_quirk' parameter to be:
>
> snb_igd_quirk => current behavior, enable
> quirk with 1 sec timeout
> snb_igd_quirk=default => enable quirk with theoretical max
> t
>>> On 14.11.14 at 16:32, wrote:
> On Fri, Nov 14, 2014 at 12:37:30PM +, Jan Beulich wrote:
>> The specification is kind of vague under what conditions
>> ExitBootServices() may legitimately fail, requiring the OS loader to
>> retry:
>>
>> "If MapKey value is incorrect, ExitBootServices() ret
Hmm, good ideas. How about I change the `snb_igd_quirk' parameter to be:
snb_igd_quirk => current behavior, enable quirk
with 1 sec timeout
snb_igd_quirk=default => enable quirk with theoretical max
timeout of 670 msec
snb_igd_qui
On Mon, 2014-11-17 at 12:35 +, Stefano Stabellini wrote:
> Many thanks for your efforts!
>
> By any chance instead of rebuilding xen from source, have you tried
> installing xen-system-amd64 (apt-get install xen-system-amd64), the xen
> package for ubuntu?
From
https://launchpadlibrarian.net/
On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:
> Hi,
>
>
> The wiki page is ready. I am not sure whether I am using the correct
> format or not. Please let me know if any changes are need. Thanks,
>
>
> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
Thanks for this. WRT
On 11/14/2014 11:12 AM, Ian Campbell wrote:
On Thu, 2014-11-13 at 19:04 +, George Dunlap wrote:
Return proper error codes on failure so that scripts can tell whether
the command completed properly or not.
Also while we're at it, normalize init and dispose of
libxl_device_disk structures. T
Many thanks for your efforts!
By any chance instead of rebuilding xen from source, have you tried
installing xen-system-amd64 (apt-get install xen-system-amd64), the xen
package for ubuntu?
On Fri, 14 Nov 2014, Xing Lin wrote:
> Hi,
>
> The wiki page is ready. I am not sure whether I am using
Can you make sure you don't specified mac for vif then
$ xl save $WIN saved.img
$ hexdump -C -n1024 saved.img
Look for nics in output and paste the it here. You might want to change
1024 to something larger if you specified many options in your config
file.
A sample output for my PV guest which
xen.org writes ("[seabios test] 31553: regressions - FAIL"):
> flight 31553 seabios real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31553/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-pair 18 gu
flight 31635 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31635/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels
fail REGR. vs. 31437
Tes
On Mon, Nov 17, 2014 at 07:18:17PM +0800, Chen, Tiejun wrote:
> On 2014/11/17 18:13, Michael S. Tsirkin wrote:
> >On Mon, Nov 17, 2014 at 05:42:12PM +0800, Chen, Tiejun wrote:
> >>On 2014/11/17 17:25, Michael S. Tsirkin wrote:
> >>>On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
> >>>
The existence check is to make sure a device is not added to a guest
multiple times.
PCI device backend path has different rules from vif, disk etc. For
example:
/local/domain/0/backend/pci/9/0/dev-1/:03:10.1
/local/domain/0/backend/pci/9/0/key-1/:03:10.1
/local/domain/0/backend/pci/9/0/de
>>> On 17.11.14 at 05:11, wrote:
> @@ -237,6 +254,18 @@
> }
> }
>
> +static void __init parse_snb_timeout(const char *s)
> +{
> +
> + if (*s == '\0')
> + snb_igd_timeout = SNB_IGD_TIMEOUT;
> + else
> + snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
>
>>> On 17.11.14 at 12:32, wrote:
> On 2014/11/17 19:17, Jan Beulich wrote:
> On 17.11.14 at 12:08, wrote:
>>
>>> On 2014/11/17 18:05, Jan Beulich wrote:
>>> On 17.11.14 at 08:57, wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -698,10 +698,13 @@ struct get
On 17/11/14 11:42, Thomas Leonard wrote:
> On 26 October 2014 10:25, Thomas Leonard wrote:
>> On 26 October 2014 09:55, Samuel Thibault
>> wrote:
>>> Thomas Leonard, le Sun 26 Oct 2014 09:46:09 +, a écrit :
Could you say a bit more about the linker problems you had?
>>> Really digging i
Thomas Leonard, le Mon 17 Nov 2014 11:42:38 +, a écrit :
> On 26 October 2014 10:25, Thomas Leonard wrote:
> > On 26 October 2014 09:55, Samuel Thibault
> > wrote:
> >> Thomas Leonard, le Sun 26 Oct 2014 09:46:09 +, a écrit :
> >>> Could you say a bit more about the linker problems you h
On 11/14/2014 09:11 AM, Fabio Fantoni wrote:
Il 26/04/2013 12:30, Fabio Fantoni ha scritto:
Il 26/04/2013 11:36, Ian Campbell ha scritto:
On Fri, 2013-04-26 at 10:24 +0100, Fabio Fantoni wrote:
Il 24/04/2013 17:36, Ian Campbell ha scritto:
On Wed, 2013-04-24 at 15:06 +0100, Fabio Fantoni wrot
On Mon, 2014-11-17 at 11:42 +, Thomas Leonard wrote:
> On 26 October 2014 10:25, Thomas Leonard wrote:
> > On 26 October 2014 09:55, Samuel Thibault
> > wrote:
> >> Thomas Leonard, le Sun 26 Oct 2014 09:46:09 +, a écrit :
> >>> Could you say a bit more about the linker problems you had?
On 26 October 2014 10:25, Thomas Leonard wrote:
> On 26 October 2014 09:55, Samuel Thibault
> wrote:
>> Thomas Leonard, le Sun 26 Oct 2014 09:46:09 +, a écrit :
>>> Could you say a bit more about the linker problems you had?
>>
>> Really digging in the archives this time :)
>>
>> ia64-specif
xen.org writes ("[xen-4.2-testing test] 31525: regressions - FAIL"):
> flight 31525 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31525/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i
On 2014/11/17 19:17, Jan Beulich wrote:
On 17.11.14 at 12:08, wrote:
On 2014/11/17 18:05, Jan Beulich wrote:
On 17.11.14 at 08:57, wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -698,10 +698,13 @@ struct get_reserved_device_memory {
unsigned int used_entries;
};
xen.org writes ("[rumpuserxen bisection] complete
test-amd64-i386-rumpuserxen-i386"):
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-rumpuserxen-i386
> test rumpuserxen-demo-xenstorels/xenstorels
We're still on the old osstest here, so this is simply confirmation of
my earl
On Sun, 16 Nov 2014, Li, Liang Z wrote:
> > > > Konrad,
> > > > this is another bug fix for QEMU: pci hotplug doesn't work when
> > > > xen_platform_pci=0 without this.
> > >
> > > Yes.
> > > >
> > > >I think we should have it in 4.5. What do yo think?
> > >
> > > Do you believe we should first ge
On 2014/11/17 18:13, Michael S. Tsirkin wrote:
On Mon, Nov 17, 2014 at 05:42:12PM +0800, Chen, Tiejun wrote:
On 2014/11/17 17:25, Michael S. Tsirkin wrote:
On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
On 2014/11/17 14:10, Michael S. Tsirkin wrote:
On Mon, Nov 17, 2014 at 10:4
>>> On 17.11.14 at 12:08, wrote:
> On 2014/11/17 18:05, Jan Beulich wrote:
> On 17.11.14 at 08:57, wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>>>unsigned int used_entries;
>>>};
>>>
>>> -static
On 2014/11/17 18:05, Jan Beulich wrote:
On 17.11.14 at 08:57, wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -698,10 +698,13 @@ struct get_reserved_device_memory {
unsigned int used_entries;
};
-static int get_reserved_device_memory(xen_pfn_t start,
-
See http://events.linuxfoundation.org/events/collaboration-summit/program/cfp
It would be great if we had a number of Xen related submissions
As an aside:
* I arranged for 1/2 day public Xen track
* And a 1/2 day of space for private meetings for members of the Xen community
planning to come to
On Mon, Nov 17, 2014 at 10:55:34AM +, Li, Liang Z wrote:
> > > The libxl__device_exists will return 1 if more than one PCI devices are
> > > attached to the guest, no matter the BDFs are identical or not.
> >
> > That means this check is problematic. I think the original intention was to
> >
On Mon, 2014-11-17 at 10:48 +, Wei Liu wrote:
> On Mon, Nov 17, 2014 at 10:42:45AM +, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 10:41 +, Wei Liu wrote:
> > > On Mon, Nov 17, 2014 at 10:25:31AM +, Ian Campbell wrote:
> > > > On Mon, 2014-11-17 at 09:52 +, Wei Liu wrote:
> > >
On Mon, 2014-11-17 at 10:42 +, Ian Campbell wrote:
> On Mon, 2014-11-17 at 10:41 +, Wei Liu wrote:
> > On Mon, Nov 17, 2014 at 10:25:31AM +, Ian Campbell wrote:
> > > On Mon, 2014-11-17 at 09:52 +, Wei Liu wrote:
> > > > > +/* update backend
> > > > > /local/domain/0/backend///
On Mon, Nov 17, 2014 at 10:42:45AM +, Ian Campbell wrote:
> On Mon, 2014-11-17 at 10:41 +, Wei Liu wrote:
> > On Mon, Nov 17, 2014 at 10:25:31AM +, Ian Campbell wrote:
> > > On Mon, 2014-11-17 at 09:52 +, Wei Liu wrote:
> > > > > +/* update backend
> > > > > /local/domain/0/bac
> > The libxl__device_exists will return 1 if more than one PCI devices are
> > attached to the guest, no matter the BDFs are identical or not.
>
> That means this check is problematic. I think the original intention was to
> check on BDFs, however it wasn't thoroughly tested. Sorry.
>
> > I don'
On Mon, 2014-11-17 at 10:41 +, Wei Liu wrote:
> On Mon, Nov 17, 2014 at 10:25:31AM +, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 09:52 +, Wei Liu wrote:
> > > > +/* update backend
> > > > /local/domain/0/backend///.../domain */
> > > > +be_dev = libxl__xs_directory(gc, trans
On Mon, Nov 17, 2014 at 10:25:31AM +, Ian Campbell wrote:
> On Mon, 2014-11-17 at 09:52 +, Wei Liu wrote:
> > > +/* update backend
> > > /local/domain/0/backend///.../domain */
> > > +be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend",
> > > &ndevs);
> >
> > The ha
On Sun, 2014-11-16 at 23:39 -0500, Tim Wood wrote:
> Hi,
>
> I am curious if Xen currently supports sharing hugepages between
> domains (specifically ones originally allocated in Dom-0 and shared
> with a guest r/w). I've seen some references to huge pages in the
> archives of this list, but not
On Mon, 2014-11-17 at 09:41 +, Wei Liu wrote:
> On Mon, Nov 17, 2014 at 05:28:58PM +0800, Chao Peng wrote:
> > Avoid sending duplicated qmp commands and eliminate the confusing error
> > messages like "Unable to add CPU: 0, it already exists".
> >
> > Signed-off-by: Chao Peng
> > ---
> > too
On Mon, 2014-11-17 at 09:52 +, Wei Liu wrote:
> > +/* update backend /local/domain/0/backend///.../domain
> > */
> > +be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend",
> > &ndevs);
>
> The hard-coded 0 cannot work if you have driver domain.
>
> At the very least it
On Mon, Nov 17, 2014 at 05:42:12PM +0800, Chen, Tiejun wrote:
> On 2014/11/17 17:25, Michael S. Tsirkin wrote:
> >On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
> >>On 2014/11/17 14:10, Michael S. Tsirkin wrote:
> >>>On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
> >>>
>>> On 17.11.14 at 08:57, wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
> unsigned int used_entries;
> };
>
> -static int get_reserved_device_memory(xen_pfn_t start,
> - xen_u
Is this a regression? Can it wait until 4.6?
On Mon, Nov 17, 2014 at 05:19:47PM +0800, Chunyan Liu wrote:
> Currently libxl__domain_rename only update /local/domain//name,
> still some places in xenstore are not updated, including:
> /vm//name and /local/domain/0/backend///.../domain.
>
I notice
On Sun, 2014-11-16 at 13:03 -0800, Christoffer Dall wrote:
> On Mon, Nov 10, 2014 at 02:09:59PM +, Ian Campbell wrote:
> > If Xen isn't enabled then XEN_IMAGE ends up as "no.o", which obviously
> > doesn't
> > exist. Handle the dependency explicitly.
> >
> > Signed-off-by: Ian Campbell
> > -
On 2014/11/17 17:25, Michael S. Tsirkin wrote:
On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
On 2014/11/17 14:10, Michael S. Tsirkin wrote:
On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
On 2014/11/5 22:09, Michael S. Tsirkin wrote:
On Wed, Nov 05, 2014 at 03:22
1 - 100 of 111 matches
Mail list logo
