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:59PM +0800, Tiejun Chen wrote:
Currently IGD drivers always need to access PCH by 1f.0, and
PCH vendor/device
flight 31626 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31626/
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
On Fri, Nov 14, 2014 at 11:19:56AM +, Ian Campbell wrote:
> On Fri, 2014-11-14 at 11:10 +, Wei Liu wrote:
> > On Fri, Nov 14, 2014 at 10:55:35AM +, Ian Campbell wrote:
> > > On Fri, 2014-11-14 at 10:52 +, Ian Campbell wrote:
> > > > On Wed, 2014-11-12 at 17:04 +, Wei Liu wrote:
On Mon, Nov 10, 2014 at 12:08:33PM +, Ian Campbell wrote:
> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> is freed by xc_dom_release. However the various xc_try_*_decode routines
> (other
> than the gzip one) just use plain malloc/realloc and therefore the buf
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.
Signed-off-by: Chunyan Liu
---
tools/libxl/libxl.c | 55 +
1 file chan
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
---
tools/libxl/libxl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index
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:59PM +0800, Tiejun Chen wrote:
> C
On Mon, 2014-11-17 at 09:16 +, Wei Liu wrote:
> > @@ -508,6 +522,10 @@ static int xc_try_lzo1x_decode(
> > if ( out_len != dst_len )
> > break;
> >
> > +msg = "Error registering stream output";
> > +if ( xc_dom_register_external(dom, out_b
On Mon, Nov 17, 2014 at 07:53:44AM +, Li, Liang Z wrote:
> > Originally the code allowed users to attach the same device more than
> > once. It just stupidly overwrites xenstore entries. This is bogus as
> > frontend will be very confused.
> >
> > Introduce a helper function to check if the dev
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
> ---
> tools/libxl/libxl.c |2 +-
> 1 file changed, 1 insertion(+), 1
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
On Sun, 2014-11-16 at 12:26 -0800, Christoffer Dall wrote:
> Hi Ian,
>
> On Mon, Nov 10, 2014 at 02:09:58PM +, Ian Campbell wrote:
> > - Include bootargs (kernel command line) property.
>
> Why?
>
> The logic I was going for was to reduce duplicate code/entries in the
> DT, and if I read doc
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
> > -
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 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
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 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, 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 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, 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 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
> > 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, 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
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, 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, 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
> >
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 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,
-
>>> 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: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 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
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 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 ("[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 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
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 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
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 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
>>> 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 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));
>
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 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:
> >>>
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
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
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
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
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
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 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/
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 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
>>> 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 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 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 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
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
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.
>>> 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
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.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 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
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 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
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 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
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
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
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
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 */
> +
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 !=
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
>>> 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
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
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
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
>>> 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 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 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
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 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
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 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 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: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
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
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
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
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 ---
> >>
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 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 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 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
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
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
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
. 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:
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
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 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
1 - 100 of 111 matches
Mail list logo
