This run is configured for baseline tests only.
flight 38203 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38203/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 19 guest-start.2
turning main function xl exit codes towards using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.
also includes a document comment in xl.h stating xl process should
always return EXIT_FOO and main_* can be treated as main() as if
they are returning
*Its my "bite size contribution" that is required for applying to the
Outreachy program.
*main_foo() is treated somewhat as a regular main(), it is changed to
return EXIT_SUCCESS or EXIT_FAILURE.
*functions that are not main_foo(), are changed to do 'return 0' or
'return 1', and then 0/1 is taken
turning scheduling related functions xl exit codes towards using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_cmdimpl.c | 147 ++-
1 file changed, 70
turning cpupools related functions xl exit codes towards using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_cmdimpl.c | 52
1 file changed, 26
turning parsing related functions xl exit codes towards using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.
it doesn't include parse_config_data() which is big enough to deserve its
own patch
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_
turning vcpu manipulation functions xl exit codes toward using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_cmdimpl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-
flight 63224 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63224/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build fail REGR. vs. 62642
Regressions which are
flight 63223 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63223/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-libvirt-pair 9 xen-boot/src_hostfail REGR. vs. 63087
test-amd64-amd64-rumpuserxen-amd
This run is configured for baseline tests only.
flight 38204 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38204/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 19 capture-logs(1
flight 63222 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63222/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 3 host-install(3) broken REGR. vs. 63117
On Fri, Oct 23, 2015 at 04:28:25PM +0100, Ross Lagerwall wrote:
> Hi all,
>
> I've gone ahead and implemented a bunch of xSplice stuff based on Konrad's
> xsplice branch. It is sitting in my github repository:
> https://github.com/rosslagerwall/xen tagged prototype-v1
> This is obviously prototype
On 10/23/2015 09:07 PM, D'Mita Levy wrote:
> Is it possible to add Xen development headers to XenServer? I would like
> to do a little bit of VM introspection with LibVMI on XenServer. I have
> all the other dependencies installed (glib, flex, etc.) just missing the
> ones for Xen...Any help is gre
On 23/10/15 19:07, D'Mita Levy wrote:
> Is it possible to add Xen development headers to XenServer? I would
> like to do a little bit of VM introspection with LibVMI on XenServer.
> I have all the other dependencies installed (glib, flex, etc.) just
> missing the ones for Xen...Any help is greatly
Is it possible to add Xen development headers to XenServer? I would like to
do a little bit of VM introspection with LibVMI on XenServer. I have all
the other dependencies installed (glib, flex, etc.) just missing the ones
for Xen...Any help is greatly appreciated.
Thanks,
D'Mita
--
D'Mita Levy
Combine the almost identical vm_launch_fail() and vm_resume_fail() into
a single vmx_vmentry_failure().
Re-save all GPRs so that domain_crash() prints the real register values,
rather than the active stack of the vmx_vmentry_failure() callpath.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
C
flight 63216 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63216/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate
fail REGR. vs. 62677
On 23/10/15 18:16, Mike wrote:
> Hello,
>
> I'm doing some reviewing of XEN source code. Does x86_emulate() (from
> x86_emulate.c) execute on every guest, or is this whenever a machine
> doesn't have hardware assisted virtualization?
By default, guests do not have instructions emulated. They run
Hello,
I'm doing some reviewing of XEN source code. Does x86_emulate() (from
x86_emulate.c) execute on every guest, or is this whenever a machine
doesn't have hardware assisted virtualization?
Thanks,
Mike
___
Xen-devel mailing list
Xen-devel@lists.xen
Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step:
Linky linky revision graph"):
> On 23/10/15 17:46, Ian Jackson wrote:
> > Yes, indeed. It appears that your browser is rather poor :-). (Most
> > are...)
>
> How is yours configured then, to do something sensible with
On 23/10/15 17:46, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step:
> Linky linky revision graph"):
>> On 23/10/15 17:35, Ian Jackson wrote:
>>> Example of the output:
>>>
>>> http://xenbits.xen.org/people/iwj/2015/bisection-svg/t.html
>>> http://x
Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step:
Linky linky revision graph"):
> On 23/10/15 17:35, Ian Jackson wrote:
> > Example of the output:
> >
> > http://xenbits.xen.org/people/iwj/2015/bisection-svg/t.html
> > http://xenbits.xen.org/people/iwj/2015/bisection-sv
flight 63260 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63260/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On 23/10/15 17:35, Ian Jackson wrote:
> Ian Jackson writes ("[OSSTEST PATCH 0/3] cs-bisection-step: Linky linky
> revision graph"):
>> These three patches contrive to produce (in a rather ugly way) an SVG
>> version of the revision graph in which the revisions and (most
>> usefully) the flights ar
Ian Jackson writes ("[OSSTEST PATCH 0/3] cs-bisection-step: Linky linky
revision graph"):
> These three patches contrive to produce (in a rather ugly way) an SVG
> version of the revision graph in which the revisions and (most
> usefully) the flights are hyperlinks.
Example of the output:
http:/
These three patches contrive to produce (in a rather ugly way) an SVG
version of the revision graph in which the revisions and (most
usefully) the flights are hyperlinks.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
We compare the revision rtuple elements with each of the parents, and
mark changes by surrounding the revision id with *asterisks*.
In the SVG output, we have to strip these when generating the URL, and
we can show this by emboldening the relevant revision instead. This
involves changing the ther
Make various elements in the output into hyperlinks and hence document
that the SVG version of the graph is best to use.
AFAICT dot does not provide a way to put literal SVG elements into its
output. So we postprocess it. Luckily we produced the input to dot
so we know a lot about what the outpu
This is going to let us provide a version with hyperlinks.
Signed-off-by: Ian Jackson
---
cs-bisection-step |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/cs-bisection-step b/cs-bisection-step
index 7a97b10..bd5a27e 100755
--- a/cs-bisection-step
+++ b/cs-bisection-s
On Fri, 2015-10-23 at 16:40 +0100, Ian Campbell wrote:
> On Fri, 2015-10-23 at 17:12 +0200, Dario Faggioli wrote:
> > On Fri, 2015-10-23 at 15:09 +0100, Ian Campbell wrote:
> > > I think what I would have been expecting is for the xl internal
> > > error
> > > code
> > Well, same here. Except, giv
flight 63214 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63214/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 4 host-build-prep fail REGR. vs. 63099
test-amd64-amd64-
On Fri, 2015-10-23 at 15:58 +0100, Julien Grall wrote:
> Is there any way we could register the IO region used on ARM without
> having to enforce it in all the drivers?
This seems like an uphill battle to me.
Why not do as I suggested IRL yesterday and expose the map of "potential
RAM" addresses
def_getopt would print a message to stderr, but blunder on anyway.
Sadly this is probably not a backport candidate.
Signed-off-by: Ian Jackson
---
tools/libxl/xl_cmdimpl.c |1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index ea43761..d
On Fri, 2015-10-23 at 17:12 +0200, Dario Faggioli wrote:
> On Fri, 2015-10-23 at 15:09 +0100, Ian Campbell wrote:
> > On Fri, 2015-10-23 at 09:43 +0100, Wei Liu wrote:
>
> > Looking at those links, I'm not sure that either you or myself was
> > thinking
> > of using EXIT_* as function return value
Hi all,
I've gone ahead and implemented a bunch of xSplice stuff based on
Konrad's xsplice branch. It is sitting in my github repository:
https://github.com/rosslagerwall/xen tagged prototype-v1
This is obviously prototype code, but please try it out. You'll also
need this tool to build patche
On Fri, 2015-10-23 at 15:09 +0100, Ian Campbell wrote:
> On Fri, 2015-10-23 at 09:43 +0100, Wei Liu wrote:
> Looking at those links, I'm not sure that either you or myself was
> thinking
> of using EXIT_* as function return values, just that the eventual
> process
> exit would become one of those
Hi all,
I've been working on trying to get balloon memory hotplug working for
ARM64 guest on Xen.
In order to find a suitable region to hotplug the fake memory, we are
trying to find a free region within iomem_resource.
But on ARM64, only an handful number of regions are listed in it. For
instan
>>> On 23.10.15 at 16:55, wrote:
> On Fri, 2015-10-23 at 15:44 +0100, Julien Grall wrote:
>> #define set_xen_guest_handle_raw(hnd, val) \
>> do { if ( sizeof(hnd) == 8 ) *(uint64_t *)&(hnd) = 0; \
>> (hnd).p = val; \
>> } whil
On Fri, 2015-10-23 at 15:44 +0100, Julien Grall wrote:
> On 23/10/15 15:37, Jan Beulich wrote:
> > > > > On 23.10.15 at 16:31, wrote:
> > > On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote:
> > > > No, the validating script is a nice-to-have, but nothing more. What
> > > > I was referring to w
>>> On 23.10.15 at 16:48, wrote:
> Perhaps this needs to be explicitly asked then, So, given:
> #define set_xen_guest_handle_raw(hnd, val) \
> do {\
> typeof(&(hnd)) _sxghr_tmp = &(hnd); \
> _s
On Fri, 2015-10-23 at 08:24 -0600, Jan Beulich wrote:
> > > > On 23.10.15 at 16:03, wrote:
> > On Fri, 2015-10-23 at 07:52 -0600, Jan Beulich wrote:
> > > > > > On 23.10.15 at 15:30, wrote:
> > > > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
> > > > > Hi,
> > > > >
> > > > > On 04/10/
On 23/10/15 15:37, Jan Beulich wrote:
On 23.10.15 at 16:31, wrote:
>> On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote:
>>> No, the validating script is a nice-to-have, but nothing more. What
>>> I was referring to was a patch to drop the use of this gcc extension.
>>
>> Then I'm confused
>>> On 23.10.15 at 16:31, wrote:
> On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote:
>> > > > On 23.10.15 at 15:58, wrote:
>> > On 23/10/15 14:52, Jan Beulich wrote:
>> > > > > > On 23.10.15 at 15:30, wrote:
>> > > > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
>> > > > > Hi,
>> >
On Fri, 2015-10-23 at 15:31 +0100, Ian Campbell wrote:
> On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote:
> > > > > On 23.10.15 at 15:58, wrote:
> > > On 23/10/15 14:52, Jan Beulich wrote:
> > > > > > > On 23.10.15 at 15:30, wrote:
> > > > > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wr
On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote:
> > > > On 23.10.15 at 15:58, wrote:
> > On 23/10/15 14:52, Jan Beulich wrote:
> > > > > > On 23.10.15 at 15:30, wrote:
> > > > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
> > > > > Hi,
> > > > >
> > > > > On 04/10/15 20:24, Julien
>>> On 23.10.15 at 15:58, wrote:
> On 23/10/15 14:52, Jan Beulich wrote:
> On 23.10.15 at 15:30, wrote:
>>> On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
Hi,
On 04/10/15 20:24, Julien Grall wrote:
> The keyword typeof is not portable:
>
> /usr/src/freebsd/s
>>> On 23.10.15 at 16:03, wrote:
> On Fri, 2015-10-23 at 07:52 -0600, Jan Beulich wrote:
>> > > > On 23.10.15 at 15:30, wrote:
>> > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
>> > > Hi,
>> > >
>> > > On 04/10/15 20:24, Julien Grall wrote:
>> > > > The keyword typeof is not portable:
On Fri, 2015-10-23 at 09:43 +0100, Wei Liu wrote:
> On Thu, Oct 22, 2015 at 07:14:20PM +0200, Dario Faggioli wrote:
> > In fact, right now, failing at destroying a cpupool is just
> > not reported to the user in any explicit way. Log an error,
> > as it is customary for xl in these cases.
> >
> >
On Fri, 2015-10-23 at 07:52 -0600, Jan Beulich wrote:
> > > > On 23.10.15 at 15:30, wrote:
> > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > On 04/10/15 20:24, Julien Grall wrote:
> > > > The keyword typeof is not portable:
> > > >
> > > > /usr/src/freebsd/sys/xen/
On Fri, 2015-10-23 at 11:33 +0100, Julien Grall wrote:
> The last parameter of alloc_domheap_page{s,} contain the memory flags
> and
> not the order of the allocation.
>
> Use 0 for the call in p2m_pod_set_cache_target as it was before
> 1069d63c5ef2510d08b83b2171af660e5bb18c63 "x86/mm/p2m: use de
On 23/10/15 14:52, Jan Beulich wrote:
On 23.10.15 at 15:30, wrote:
>> On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
>>> Hi,
>>>
>>> On 04/10/15 20:24, Julien Grall wrote:
The keyword typeof is not portable:
/usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit de
On Thu, 2015-10-08 at 12:10 -0400, Zhigang Wang wrote:
> On 10/08/2015 11:28 AM, Ian Campbell wrote:
> > On Thu, 2015-10-08 at 10:58 -0400, Zhigang Wang wrote:
> > > On 10/08/2015 10:40 AM, Ian Campbell wrote:
> > > > On Tue, 2015-10-06 at 15:09 -0400, Konrad Rzeszutek Wilk wrote:
> > > > > On Tue,
On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
> Hi,
>
> On 04/10/15 20:24, Julien Grall wrote:
> > The keyword typeof is not portable:
> >
> > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
> > of function 'typeof' is invalid in C99
> > [-Werror,-Wimplicit-functi
El 23/10/15 a les 13.33, Roger Pau Monné ha escrit:
> El 23/10/15 a les 7.53, Надежда Ампилогова ha escrit:
>> Hi all,
>>
>> I am interested in the project Refactor Linux hotplug scripts for
>> Outreachy(Round 11). I am more of an intermediate-beginner in c. Please can
>> anyone provide some poin
On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> The GICv2 DT node is usually used by the guest to know the address/size
> of the regions (GICD, GICC...) to map into their virtual memory.
>
> While the GICv2 spec requires the size of the GICC to be 8KB, we
> correctly do an 8KB stage-2 map
On Fri, 2015-10-23 at 14:34 +0100, Julien Grall wrote:
> Hi Ian,
>
> On 23/10/15 14:28, Ian Campbell wrote:
> > On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> > > The GICv2 DT node is usually used by the guest to know the
> > > address/size
> > > of the regions (GICD, GICC...) to map int
On 10/21/2015 07:10 PM, Dario Faggioli wrote:
On Thu, 2015-10-15 at 10:25 +0200, Juergen Gross wrote:
Maybe it would be a good idea to move setting of per_cpu(cpupool,
cpu)
into schedule_cpu_switch(). Originally I didn't do that to avoid
spreading too much cpupool related actions outside of cpup
On Fri, 2015-10-23 at 13:25 +, Hu, Robert wrote:
> > -Original Message-
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: Friday, October 23, 2015 4:15 PM
> > To: Hu, Robert ; 'Ian Jackson'
> > ; 'xen-de...@lists.xenproject.org'
> >
> > Subject: Re: [OSSTEST PATCH 26/26
On Fri, 2015-10-23 at 15:16 +0200, Fabio Fantoni wrote:
> A recent ovmf patch (already tested) I think is good to backport is:
Pointing out backport candidates in the depths of a thread such as this is
a sure fire way to ensure they get missed I'm afraid.
Please make such requests explicitly in a
On 23/10/15 13:57, Julien Grall wrote:
> The function add_memory_resource take in parameter a resource allocated
> by the caller. On error, both add_memory_resource and the caller will
> release the resource via release_memory_source.
[...]
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
>
On 23/10/15 14:39, Ian Campbell wrote:
> On Fri, 2015-10-23 at 14:34 +0100, Julien Grall wrote:
>> Hi Ian,
>>
>> On 23/10/15 14:28, Ian Campbell wrote:
>>> On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
The GICv2 DT node is usually used by the guest to know the
address/size
o
On Fri, 2015-10-23 at 15:42 +0200, Juergen Gross wrote:
> On 10/21/2015 07:10 PM, Dario Faggioli wrote:
> > Also, all the operations done in schedule_cpu_switch() itself,
> > depend
> > either on per_cpu(scheduler) or on per_cpu(schedule_data) being
> > updated
> > properly, rather than on per_cpu
On Thu, 2015-10-22 at 17:22 +0100, Ian Campbell wrote:
> On Thu, 2015-10-22 at 16:39 +0100, Ian Jackson wrote:
> > assert is not async-signal-safe.
>
> I don't doubt you, but I'm curious regarding a reference.
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/assert.html doe
> sn
> 't
>>> On 23.10.15 at 15:30, wrote:
> On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
>> Hi,
>>
>> On 04/10/15 20:24, Julien Grall wrote:
>> > The keyword typeof is not portable:
>> >
>> > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
>> > of function 'typeof' is in
On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> Hi all,
>
> Only patch #3 is related to the subject of the cover letter. The rest is
> clean
> up of code I looked while I was working on this series. Though, patch #1
> is a
> new bug fix I noticed between v3 and v4.
I fixed the typos I me
On Fri, 2015-10-23 at 11:39 +0100, Julien Grall wrote:
> On 23/10/15 11:39, Ian Campbell wrote:
> > On Thu, 2015-10-22 at 18:17 +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > On 22/10/15 16:42, Ian Campbell wrote:
> > > > On Mon, 2015-10-12 at 16:39 +0100, Julien Grall wrote:
> > > >
> > > > Su
Hi Ian,
On 23/10/15 14:28, Ian Campbell wrote:
> On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
>> The GICv2 DT node is usually used by the guest to know the address/size
>> of the regions (GICD, GICC...) to map into their virtual memory.
>>
>> While the GICv2 spec requires the size of the
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Friday, October 23, 2015 4:15 PM
> To: Hu, Robert ; 'Ian Jackson'
> ; 'xen-de...@lists.xenproject.org'
>
> Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
>
On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> All the quirks has been replaced by proper detection. Lets drop the
have
> callback and hope that no one will need new quirks.
>
> At the same time, remove the definition platform_dom0_evtchn_ppi with is
On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> We are currently using a per-platform quirk to know if the 2 4KB region
> of
> the GIC CPU interface are each aligned to 64KB. Although, it may be
> possible to have different layout on a same platform (depending on the
> firmware version).
>
On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> The size of the CPU interface will used in a follow-up patch to map the
^be
> region in Xen memory.
>
> Based on GICv2 spec, the CPU interface should at least be 8KB, although
> most of the platform we a
flight 63212 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63212/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate.2 fail in 63151 pass
in 63212
test-amd64-i386-xl-qem
Il 23/10/2015 14:56, Ian Campbell ha scritto:
On Fri, 2015-10-23 at 13:43 +0100, Stefano Stabellini wrote:
We have no existing stable baseline for that arch, and no testing or
reason to believe that cb9a7eb (the Config.mk version currently
referenced by 4.6) as being any good at all on that plat
On Fri, Oct 23, 2015 at 5:40 PM, Dario Faggioli
wrote:
> > int main_cpupooldestroy(int argc, char **argv)
> > @@ -7580,13 +7580,13 @@ int main_cpupooldestroy(int argc, char
> > **argv)
> > if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, &poolid,
> > NULL) ||
> > !libxl_cpupooli
Hi,
On 04/10/15 20:24, Julien Grall wrote:
> The keyword typeof is not portable:
>
> /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
> of function 'typeof' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
Ping? Aside the fact that other bits of the header may
In tools/libxc/xc_dom_compat_linux.c xc_linux_build() is the only
domain building function used by an in-tree component (qemu-xen) which
is really necessary.
Remove the other domain building functions and the unused python
wrapper xc.linux_build() referencing one of the to be removed
functions.
S
Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of domain handling related python binding left. Remove them.
Signed-off-by: Juergen Gross
---
tools/python/xen/lowlevel/xc/xc.c | 358 ---
Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any flask related python binding left. Remove them.
Signed-off-by: Juergen Gross
---
tools/python/xen/lowlevel/xc/xc.c | 238 -
Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any cpupool related python binding left. Remove them.
Signed-off-by: Juergen Gross
---
tools/python/xen/lowlevel/xc/xc.c | 224 ---
Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any cpuid related python binding left. Remove them.
Signed-off-by: Juergen Gross
---
tools/python/xen/lowlevel/xc/xc.c | 128 -
Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of most memory related python binding left. Remove them.
Especially xc.domain_set_target_mem() and xc.domain_setmaxmem() will
not be removed as there are so
Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of hvm related python binding left. Remove them.
Signed-off-by: Juergen Gross
---
tools/python/xen/lowlevel/xc/xc.c | 92
Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any scheduler related python binding left. Remove them.
Signed-off-by: Juergen Gross
---
tools/python/xen/lowlevel/xc/xc.c | 133 -
xc_get_bit_size() is being used by the unused python wrapper
xc.getBitSize() only. Remove the wrapper and xc_get_bit_size().
Signed-off-by: Juergen Gross
---
tools/libxc/include/xenguest.h| 4
tools/libxc/xc_dom_compat_linux.c | 25 -
tools/python/xen/lowlevel/x
Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there are
only some few python bindings in use, most of the in out of tree
tools. Remove all unused libxc python bindings.
Signed-off-by: Juergen Gross
---
tools/python/x
Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any device related python binding left. Remove them.
Signed-off-by: Juergen Gross
---
tools/python/xen/lowlevel/xc/xc.c | 226
Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of vcpu related python binding left. Remove them.
Signed-off-by: Juergen Gross
---
tools/python/xen/lowlevel/xc/xc.c | 134 --
This series is a combination of my previous patches:
"libxc: remove most of tools/libxc/xc_dom_compat_linux.c"
"tools: remove unused wrappers for python"
I have split it up as requested by Ian Campbell, thus it consists of
13 patches instead just of 2, but the functionality is roughly the
same.
Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of permission related python binding left. Remove them.
Signed-off-by: Juergen Gross
---
tools/python/xen/lowlevel/xc/xc.c | 97
The function add_memory_resource take in parameter a resource allocated
by the caller. On error, both add_memory_resource and the caller will
release the resource via release_memory_source.
This will result to Linux crashing when the caller is trying to release
the resource:
CPU: 1 PID: 45 Comm:
On Fri, 2015-10-23 at 13:43 +0100, Stefano Stabellini wrote:
> > We have no existing stable baseline for that arch, and no testing or
> > reason to believe that cb9a7eb (the Config.mk version currently
> > referenced by 4.6) as being any good at all on that platform,
> > whether we backport a coupl
On Fri, 2015-10-23 at 13:38 +0100, David Vrabel wrote:
> On 23/10/15 13:37, Ian Campbell wrote:
> > On Fri, 2015-10-23 at 12:05 +0100, David Vrabel wrote:
> > > When injecting an interrupt for a passthrough device into a guest,
> > > the
> > > per-domain event_lock is held, reducing performance whe
On Fri, 23 Oct 2015, Ian Campbell wrote:
> On Fri, 2015-10-23 at 12:18 +0100, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> > changeset"):
> > > On Fri, 23 Oct 2015, Ian Campbell wrote:
> > > > Yes. Those (that?) and the reasons why we aren't just trivially
On Fri, 2015-10-23 at 12:06 +0100, Stefano Stabellini wrote:
> On Wed, 21 Oct 2015, Ian Campbell wrote:
> > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > separate libraries which will provide backward and forward API and ABI
> > compatiblity.
> >
> > One such library will be
On Fri, 2015-10-23 at 12:05 +0100, David Vrabel wrote:
> When injecting an interrupt for a passthrough device into a guest, the
> per-domain event_lock is held, reducing performance when a guest has
> many VCPUs and high interrupt rates.
Did you CC me due to a possible impact on ARM? If so then I
On 23/10/15 13:37, Ian Campbell wrote:
> On Fri, 2015-10-23 at 12:05 +0100, David Vrabel wrote:
>> When injecting an interrupt for a passthrough device into a guest, the
>> per-domain event_lock is held, reducing performance when a guest has
>> many VCPUs and high interrupt rates.
>
> Did you CC m
On Fri, 2015-10-23 at 12:31 +0100, Stefano Stabellini wrote:
> > diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> > index 2a5f27a..38293b4 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -6,6 +6,17 @@
> > #include
> > #include
>
On Fri, 2015-10-23 at 12:35 +0100, Stefano Stabellini wrote:
> On Fri, 23 Oct 2015, Ian Campbell wrote:
> > On Fri, 2015-10-23 at 12:12 +0100, Stefano Stabellini wrote:
> > > @@ -2113,6 +2117,15 @@ if test "$xen_pci_passthrough" != "no"; then
> > > >fi
> > > > fi
> > > >
> > > > +if test "$x
On Fri, 2015-10-23 at 12:18 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> changeset"):
> > On Fri, 23 Oct 2015, Ian Campbell wrote:
> > > Yes. Those (that?) and the reasons why we aren't just trivially
> > > taking them
> > > are explained in the refer
And here we are at the last patch of this series.
Allow me to say that this is quite good a first contribution! Thanks
for this, and I'm looking forward to seeing version 2!! :-D
About this patch, a few comments below.
On Fri, 2015-10-23 at 13:18 +0530, Harmandeep Kaur wrote:
> turning cpupools
1 - 100 of 197 matches
Mail list logo
