On 03/10/15 19:39, Konrad Rzeszutek Wilk wrote:
> And also remove the extra space. 'gmfn' does not exist in this
> function anymore.
>
> Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On 03/10/15 19:39, Konrad Rzeszutek Wilk wrote:
> I get compile warnings telling me that
>s->connections[i].fd == fd
>
> 'i' may be past the array. Adding in an extra condition
> on the loop fixes that.
>
> Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Andrew Cooper
Furthermore, I can't
On Sat, 2015-10-03 at 19:32 +, osstest service owner wrote:
> flight 62580 qemu-upstream-4.4-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/62580/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-am
Knowing which modules are loaded can be useful.
/proc/modules is slightly less human-readable than the output of
"lsmod", but also includes the load address, which might plausibly be
useful for decoding a stack trace (although I've never used it for
that myself)
Signed-off-by: Ian Campbell
---
On Sun, 2015-10-04 at 17:46 +, osstest service owner wrote:
> flight 62616 xen-4.4-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/62616/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-x
El 03/10/15 a les 21.35, Julien Grall ha escrit:
> Hi,
>
> On 30/09/2015 15:02, Ian Campbell wrote:
>> On Wed, 2015-09-30 at 15:49 +0200, Fabio Fantoni wrote:
>>> I still not found a good and "all-in-one" solution but I saw this open
>>> source project: patchwork http://jk.ozlabs.org/projects/patc
On 02/10/15 16:48, Roger Pau Monne wrote:
> Introduce a bitmap in x86 xen_arch_domainconfig that allows enabling or
> disabling specific devices emulated inside of Xen for HVM guests.
>
> Signed-off-by: Roger Pau Monné
> Acked-by: Wei Liu
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Cam
On 02/10/15 16:48, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Jun Nakajima
> Cc: Eddie Dong
> Cc: Kevin Tian
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
ht
On Mon, 2015-10-05 at 11:32 +0200, Roger Pau Monné wrote:
>
[...]
> It has drawbacks however:
> [...]
> - Comments/reviews can only be done using the web interface.
That's a show stopper IMHO.
> - Everyone would have to switch the workflow, I don't know anyway to
> get it integrated with mail
On 02/10/15 16:48, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
> Cc: Jan Beulich
> Cc: Andrew Cooper
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, 2015-10-02 at 19:21 +0100, Andrew Cooper wrote:
> On 02/10/15 18:52, Juergen Gross wrote:
> > On 10/02/2015 07:43 PM, Wei Liu wrote:
> > > Hi all
> > >
> > > As I understand it in the past there were discussions on release
> > > every
> > > 6 months. I would like to revisit this topic.
> >
El 05/10/15 a les 11.40, Ian Campbell ha escrit:
> On Mon, 2015-10-05 at 11:32 +0200, Roger Pau Monné wrote:
>>
> [...]
>
>> It has drawbacks however:
>> [...]
>> - Comments/reviews can only be done using the web interface.
>
> That's a show stopper IMHO.
>
>> - Everyone would have to switch t
flight 62642 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62642/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2
fail blocked in 60670
test-amd64
On Fri, 2015-10-02 at 18:43 +0100, Wei Liu wrote:
> # Proposed release cycle
>
> Aim for 6 months release cycle -- 4 months development period, 2
> months hardening period. Make two releases per year.
>
> Fixed hard cut-off date, no more freeze exception. Arrange RCs
> immediately after cut-off.
On 10/05/2015 11:45 AM, Ian Campbell wrote:
On Fri, 2015-10-02 at 19:21 +0100, Andrew Cooper wrote:
On 02/10/15 18:52, Juergen Gross wrote:
On 10/02/2015 07:43 PM, Wei Liu wrote:
Hi all
As I understand it in the past there were discussions on release
every
6 months. I would like to revisit th
>>> On 16.09.15 at 23:01, wrote:
> +### Symbol names
> +
> +
> +Xen as it is now, has a couple of non-unique symbol names which will
> +make runtime symbol identification hard. Sometimes, static symbols
> +simply have the same name in C files, sometimes such symbols get
> +included via header fil
>>> On 02.10.15 at 17:48, wrote:
> --- a/xen/common/compat/domain.c
> +++ b/xen/common/compat/domain.c
> @@ -23,6 +23,8 @@ CHECK_SIZE_(struct, vcpu_info);
> CHECK_vcpu_register_vcpu_info;
> #undef xen_vcpu_register_vcpu_info
>
> +extern vcpu_info_t dummy_vcpu_info;
This need to be put in a he
On Sun, Oct 4, 2015 at 12:37 PM, Bilal Bakht Ahmad wrote:
> Is there any way the contents of 2 frames be swapped given their gmfn/mfn?
Probably?
Your question isn't very detailed; you might benefit from reading this:
http://wiki.xenproject.org/wiki/Asking_Developer_Questions
Would the followin
>>> On 02.10.15 at 20:23, wrote:
> On 02/10/15 16:48, Roger Pau Monne wrote:
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index bbec0e8..63b7a24 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -2412,7 +2412,8 @@ static void vmx_ins
Ian Campbell writes ("[PATCH OSSTEST] ts-logs-capture: Gather /proc/modules"):
> Knowing which modules are loaded can be useful.
>
> /proc/modules is slightly less human-readable than the output of
> "lsmod", but also includes the load address, which might plausibly be
> useful for decoding a stac
On Mon, Oct 05, 2015 at 10:55:37AM +0100, Ian Campbell wrote:
[...]
> > Take into account holiday seasons in US, Europe and China, the two
> > cut-off dates are the Fridays in which that last day of March and
> > September are in.
>
> I can't actually parse(*) this but +1 to the concept of having
Ian Campbell writes ("[PATCH OSSTEST v5 1/2] ms-flights-summary: Produce an
HTML report of all active flights"):
> Jobs are categorised by a new ->Job field. This is added by
> ts-hosts-alllocate-Executive and propagated by the planner after
> recent patches. It contains $flight.$job.
>
> Jobs wh
>>> On 05.10.15 at 11:29, wrote:
> On Sun, 2015-10-04 at 17:46 +, osstest service owner wrote:
>> flight 62616 xen-4.4-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/62616/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests
On 09/16/2015 10:01 PM, Konrad Rzeszutek Wilk wrote:
+### Generation of xSplice ELF payloads
+
+The design of that is not discussed in this design.
+
+The author of this design envisions objdump and objcopy along
+with special GCC parameters (see above) to create .o.xsplice files
+which can be us
On 02/10/15 16:48, Roger Pau Monne wrote:
> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down and
> VCPUOP_is_up hypercalls from HVM guests.
>
> This patch introduces a new structure (vcpu_hvm_context) that should be used
> in conjuction with the VCPUOP_initialise hypercall in order
On Fri, Oct 2, 2015 at 6:43 PM, Wei Liu wrote:
> Hi all
>
> As I understand it in the past there were discussions on release every
> 6 months. I would like to revisit this topic.
>
> # Rationale for a shorter release cycle
>
> The current 9 months cadence is too long. That create at least two
> pr
>>> On 04.10.15 at 21:24, 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]
Actually, it's worse than that - typeof() is a gcc extension, an
>>> On 03.10.15 at 20:39, wrote:
> The elf_init function uses the log callback to report
> errors. But it also memsets the whole structure so the
> log callback (if set) is wiped out!
Only if you set it before calling elf_init(), which - looking at all current
in-tree users isn't intended.
Jan
On 02/10/15 16:49, Roger Pau Monne wrote:
> This structure contains the physical address of the command line, as well as
> the physical address of the list of loaded modules. The physical address of
> this structure is passed to the guest at boot time in the %ebx register.
>
> Signed-off-by: Roger
On Mon, Oct 05, 2015 at 11:29:35AM +0100, George Dunlap wrote:
[...]
> >
> > With the proposed scheme, the dates will be:
> >
> > - 4.7 cut-off date: April 1, 2016
> > - 4.7 release date: June 1, 2016
> >
> > - 4.8 cut-off date: September 30, 2016
> > - 4.8 release date: December 2, 2016
> >
>
>>> On 05.10.15 at 10:49, wrote:
> On 03/10/15 19:39, Konrad Rzeszutek Wilk wrote:
>> I get compile warnings telling me that
>>s->connections[i].fd == fd
>>
>> 'i' may be past the array. Adding in an extra condition
>> on the loop fixes that.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk
>
> Re
Ian Campbell writes ("[PATCH OSSTEST v2 1/3] cs-adjust-flight: Add job-status
to report job stats"):
> Since this new op is not a change adjust the doc comment accordingly.
Good idea. (I have already introduced another op which is not a
change: jobs-list.)
> While there add a doc string for the
Ian Campbell writes ("[PATCH OSSTEST v2 3/3] standalone: Make it possible to
pass options to run-test"):
> Currently the remainder of the comnand line is passed after the host=
> ident, which allows for other idents to be given, which isn't all that
> useful in practice.
...
> + options=
> +
El 05/09/15 a les 14.39, Bob Liu ha escrit:
> Prepare patch for multi hardware queues/rings, the ring number was set to 1 by
> force.
>
> * Use 'nr_rings' in per dev_info to identify how many hw queues/rings are
> supported, and a pointer *rinfo for all its rings.
> * Rename 'nr_ring_pages' => '
flight 38123 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38123/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail REGR. vs.
38092
test-
>>> On 02.10.15 at 19:43, wrote:
> The main objection from previous discussion seems to be that "shorter
> release cycle creates burdens for downstream projects". I couldn't
> quite get the idea, but I think we can figure out a way to sort that
> out once we know what exactly the burdens are.
I d
On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote:
> >>> On 02.10.15 at 19:43, wrote:
> > The main objection from previous discussion seems to be that "shorter
> > release cycle creates burdens for downstream projects". I couldn't
> > quite get the idea, but I think we can figure out a w
Dear Community members,
we recently did survey amongst maintainers on a number of issues that were
raised during the Xen Project developer meeting. I had 12 responses and wanted
to share the output + some initial analysis for further discussion. I got
really rather a lot of feedback and I trie
>>> On 05.10.15 at 13:23, wrote:
> On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote:
>> >>> On 02.10.15 at 19:43, wrote:
>> > The main objection from previous discussion seems to be that "shorter
>> > release cycle creates burdens for downstream projects". I couldn't
>> > quite get the
On 5/10/2015 10:23 PM, Wei Liu wrote:
> On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote:
> On 02.10.15 at 19:43, wrote:
>>> The main objection from previous discussion seems to be that "shorter
>>> release cycle creates burdens for downstream projects". I couldn't
>>> quite get the
On Mon, 2015-10-05 at 12:23 +0100, Wei Liu wrote:
> we can pick a stable tree every X releases etc etc.
I think switching to an LTS style model, i.e. only supporting 1/N for
longer than it takes to release the next major version might be interesting
to consider. I'm thinking e.g. of N=4 with a 6 m
On 5/10/2015 10:44 PM, Ian Campbell wrote:
> On Mon, 2015-10-05 at 12:23 +0100, Wei Liu wrote:
>> we can pick a stable tree every X releases etc etc.
>
> I think switching to an LTS style model, i.e. only supporting 1/N for
> longer than it takes to release the next major version might be interest
On 10/05/2015 01:44 PM, Ian Campbell wrote:
On Mon, 2015-10-05 at 12:23 +0100, Wei Liu wrote:
we can pick a stable tree every X releases etc etc.
I think switching to an LTS style model, i.e. only supporting 1/N for
longer than it takes to release the next major version might be interesting
to
On Mon, 2015-10-05 at 13:51 +0200, Juergen Gross wrote:
> On 10/05/2015 01:44 PM, Ian Campbell wrote:
> > On Mon, 2015-10-05 at 12:23 +0100, Wei Liu wrote:
> > > we can pick a stable tree every X releases etc etc.
> >
> > I think switching to an LTS style model, i.e. only supporting 1/N for
> > lo
flight 62644 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62644/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-vhd9 debian-di-install fail REGR. vs. 60565
test-am
The guest may try to load data from the emulated MMIO region using
instructions with Sign-Extension (i.e ldrs*). Any use of one those,
will set the SSE bit (Syndrome Sign Extend) in the ISS (see B3-1433
in DDI 0406C.b).
Note that the bit can only be set for access size smaller than the
register si
Hi all,
This series aims to fix the 32-bit access on 64-bit register. Some guest
OS such as FreeBSD and Linux (only in the ITS) use 32-bit access and will
crash at boot time.
I took the opportunity to go further and optimize the way Xen is storing
registers such as GICD_IPRIORITYR, GICD_ITARGETR
On Mon, Oct 05, 2015 at 05:37:32AM -0600, Jan Beulich wrote:
> >>> On 05.10.15 at 13:23, wrote:
> > On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote:
> >> >>> On 02.10.15 at 19:43, wrote:
> >> > The main objection from previous discussion seems to be that "shorter
> >> > release cycle
This typedef is a left-over of the previous MMIO emulation
implementation.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v2:
- Add Ian's Acked-by
Changes in v1:
- Patch added
---
xen/include/asm-arm/mmio.h | 1 -
1 file changed, 1 deletion(-)
diff
Having in hand the index for the rank is very handy to avoid computing
it everytime.
For now, use it when enabling/disabling the vIRQs rather than a formula
which is not obvious to understand.
Also drop the comments which where wrong because a shift by DABT_WORD
will not give the IRQ number but t
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v2:
- Add Ian's acked-by
Changes in v1:
- Patch added
---
xen/include/asm-arm/domain.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-ar
Rather than letting each handler to retrieve the register used by the
I/O access, add a new parameter to pass the register in parameter.
This will help to implement generic register manipulation on I/O access
such as sign-extension and endianess.
Read handlers need to modify the value of the regi
Xen is currently directly storing the value of GICD_IPRIORITYR register
in the rank. This makes emulation of the register access very simple
but makes the code to get the priority for a given vIRQ more complex.
While the priority of an vIRQ is retrieved every time an vIRQ is injected
to the guest,
Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers
supports both 32-bit and 64-bits access.
All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access.
For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway,
emulating 32-bit access for t
Xen is currently directly storing the value of GICD_ITARGETSR register
(for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the
emulation of the registers access very simple but makes the code to get
the target vCPU for a given vIRQ more complex.
While the target vCPU of an vIRQ is ret
and use them in the vGIC emulation.
The GIC registers may support different access sizes. Rather than open
coding the access for every registers, provide a set of helpers to access
them.
The caller will have to call vgic_regN_* where N is the size of the
emulated registers.
The new helpers suppo
On Mon, Oct 05, 2015 at 12:55:00PM +0100, Ian Campbell wrote:
> On Mon, 2015-10-05 at 13:51 +0200, Juergen Gross wrote:
> > On 10/05/2015 01:44 PM, Ian Campbell wrote:
> > > On Mon, 2015-10-05 at 12:23 +0100, Wei Liu wrote:
> > > > we can pick a stable tree every X releases etc etc.
> > >
> > > I
On 05/10/15 13:51, Julien Grall wrote:
> Rather than letting each handler to retrieve the register used by the
> I/O access, add a new parameter to pass the register in parameter.
>
> This will help to implement generic register manipulation on I/O access
> such as sign-extension and endianess.
>
Hi Steven
On Mon, Oct 05, 2015 at 10:44:30PM +1100, Steven Haigh wrote:
> On 5/10/2015 10:23 PM, Wei Liu wrote:
> > On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote:
> > On 02.10.15 at 19:43, wrote:
> >>> The main objection from previous discussion seems to be that "shorter
> >>> r
On Mon, Oct 5, 2015 at 12:44 PM, Steven Haigh wrote:
> On 5/10/2015 10:23 PM, Wei Liu wrote:
>> On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote:
>> On 02.10.15 at 19:43, wrote:
The main objection from previous discussion seems to be that "shorter
release cycle creates bu
Having the internals of xc_cpuid_policy() make hypercalls to collect domain
information causes xc_cpuid_apply_policy() to be very inefficient.
Re-order operations to collect all information at once at the outermost layer,
and pass a structure in to all cpuid policy generation functions.
This remo
On 02/10/15 05:40, Juergen Gross wrote:
> Use a bit mask for testing of a set bit instead of test_bit in case no
> atomic operation is needed, as this will lead to smaller and more
> effective code.
>
> Signed-off-by: Juergen Gross
I'm a bit confused here -- exactly when is an atomic operation n
On 6/10/2015 12:05 AM, George Dunlap wrote:
> On Mon, Oct 5, 2015 at 12:44 PM, Steven Haigh wrote:
>> On 5/10/2015 10:23 PM, Wei Liu wrote:
>>> On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote:
>>> On 02.10.15 at 19:43, wrote:
> The main objection from previous discussion seems
On 02/10/15 05:40, Juergen Gross wrote:
> Use a bit mask for testing of a set bit instead of test_bit in case no
> atomic operation is needed, as this will lead to smaller and more
> effective code.
>
> Signed-off-by: Juergen Gross
On a side note, a handful of functions seem to access the vcpu s
On 02/10/15 05:40, Juergen Gross wrote:
> Use a bit mask for testing of a set bit instead of test_bit in case no
> atomic operation is needed, as this will lead to smaller and more
> effective code.
>
> Signed-off-by: Juergen Gross
Acked-by: George Dunlap
> ---
> xen/common/sched_rt.c | 4 ++-
>>> On 05.10.15 at 14:52, wrote:
> On Mon, Oct 05, 2015 at 05:37:32AM -0600, Jan Beulich wrote:
>> >>> On 05.10.15 at 13:23, wrote:
>> > On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote:
>> >> >>> On 02.10.15 at 19:43, wrote:
>> >> > The main objection from previous discussion seems t
On 02/10/15 05:40, Juergen Gross wrote:
> Use a bit mask for testing of a set bit instead of test_bit in case no
> atomic operation is needed, as this will lead to smaller and more
> effective code.
>
> Signed-off-by: Juergen Gross
Acked-by: George Dunlap
> ---
> xen/common/sched_credit2.c |
>>> On 05.10.15 at 15:18, wrote:
> On 02/10/15 05:40, Juergen Gross wrote:
>> Use a bit mask for testing of a set bit instead of test_bit in case no
>> atomic operation is needed, as this will lead to smaller and more
>> effective code.
>>
>> Signed-off-by: Juergen Gross
>
> I'm a bit confused
Julien Grall writes ("Re: [Xen-devel] [PATCH] build: drop unused SUBARCH
variable"):
> Jan tends to not notify when a patch has been committed. It's in the
> tree since last week:
>
> commit 063792541db41167db9467feadb700de64cfcd16
> Author: Doug Goldstein
> Date: Mon Sep 21 16:14:19 2015 +020
On 10/05/2015 03:18 PM, George Dunlap wrote:
On 02/10/15 05:40, Juergen Gross wrote:
Use a bit mask for testing of a set bit instead of test_bit in case no
atomic operation is needed, as this will lead to smaller and more
effective code.
Signed-off-by: Juergen Gross
I'm a bit confused here -
On Sun, Oct 04, 2015 at 08:24:02PM +0100, 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]
>
> Signed-off-by: Julien Grall
>
>>> On 05.10.15 at 15:24, wrote:
> On 02/10/15 05:40, Juergen Gross wrote:
>> Use a bit mask for testing of a set bit instead of test_bit in case no
>> atomic operation is needed, as this will lead to smaller and more
>> effective code.
>>
>> Signed-off-by: Juergen Gross
>
> On a side note, a h
On Mon, 2015-10-05 at 11:50 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v2 3/3] standalone: Make it possible
> to pass options to run-test"):
> > Currently the remainder of the comnand line is passed after the host=
> > ident, which allows for other idents to be given, which is
On 05/10/15 14:36, Jan Beulich wrote:
On 05.10.15 at 15:18, wrote:
>> On 02/10/15 05:40, Juergen Gross wrote:
>>> Use a bit mask for testing of a set bit instead of test_bit in case no
>>> atomic operation is needed, as this will lead to smaller and more
>>> effective code.
>>>
>>> Signed-off
On 10/05/2015 02:55 PM, Wei Liu wrote:
On Mon, Oct 05, 2015 at 12:55:00PM +0100, Ian Campbell wrote:
On Mon, 2015-10-05 at 13:51 +0200, Juergen Gross wrote:
On 10/05/2015 01:44 PM, Ian Campbell wrote:
On Mon, 2015-10-05 at 12:23 +0100, Wei Liu wrote:
we can pick a stable tree every X releases
On Mon, Oct 05, 2015 at 07:31:05AM -0600, Jan Beulich wrote:
> >>> On 05.10.15 at 14:52, wrote:
> > On Mon, Oct 05, 2015 at 05:37:32AM -0600, Jan Beulich wrote:
> >> >>> On 05.10.15 at 13:23, wrote:
> >> > On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote:
> >> >> >>> On 02.10.15 at 19:
On Mon, 2015-10-05 at 11:48 +0100, Ian Jackson wrote:
> > +});
> > +}
>
> This output format is awkward, isn't it ?
>
> Would it be too horrible to omit `$job ' if the spec was a literal and
> can therefore only match one item ? You can test that with something
> like
> print "$job " or
Daniel,
now that we have MMCFG write intercepts in place, wouldn't it make
sense to move that hook invocation into pci_conf_write_intercept()
for the write case, so that it also covers MMCFG-based writes?
Thanks, Jan
___
Xen-devel mailing list
Xen-dev
>>> On 05.10.15 at 15:45, wrote:
> On 05/10/15 14:36, Jan Beulich wrote:
> On 05.10.15 at 15:18, wrote:
>>> On 02/10/15 05:40, Juergen Gross wrote:
Use a bit mask for testing of a set bit instead of test_bit in case no
atomic operation is needed, as this will lead to smaller and mor
>>> On 05.10.15 at 15:51, wrote:
> On Mon, Oct 05, 2015 at 07:31:05AM -0600, Jan Beulich wrote:
>> >>> On 05.10.15 at 14:52, wrote:
>> > On Mon, Oct 05, 2015 at 05:37:32AM -0600, Jan Beulich wrote:
>> >> >>> On 05.10.15 at 13:23, wrote:
>> >> > On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beuli
El 05/09/15 a les 14.39, Bob Liu ha escrit:
> The per device io_lock became a coarser grained lock after multi-queues/rings
> was introduced, this patch converts it to a fine-grained per ring lock.
>
> NOTE: The per dev_info structure was no more protected by any lock.
I would rewrite this as:
N
All the quirks has been replaced by proper detection. Lets drop the
callback and hope that no one will need new quirks.
At the same time, remove the definition platform_dom0_evtchn_ppi with is
not used any more.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v2:
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).
Rather than having a quirk it's possible to detect by reading the
Hi all,
Only patch #2 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.
For all changes see in each patch.
Sincerely yours,
Julien Grall (3):
xen/arm: gic: Check the size of the CPU and vCPU interface retrieved
from DT
The size of the CPU interface will used in a follow-up patch to map the
region in Xen memory.
Based on GICv2 spec, the CPU interface should at least be 8KB, although
most of the platform we are supporting use incorrectly the GICv1 size
(i.e 4KB) in their DT. Only warn and update the size to avoid
On Mon, Oct 05, 2015 at 04:36:43AM -0600, Jan Beulich wrote:
> >>> On 03.10.15 at 20:39, wrote:
> > The elf_init function uses the log callback to report
> > errors. But it also memsets the whole structure so the
> > log callback (if set) is wiped out!
>
> Only if you set it before calling elf_in
On Mon, Oct 05, 2015 at 04:46:55AM -0600, Jan Beulich wrote:
> >>> On 05.10.15 at 10:49, wrote:
> > On 03/10/15 19:39, Konrad Rzeszutek Wilk wrote:
> >> I get compile warnings telling me that
> >>s->connections[i].fd == fd
> >>
> >> 'i' may be past the array. Adding in an extra condition
> >>
On Mon, Oct 05, 2015 at 03:51:21PM +0200, Juergen Gross wrote:
> On 10/05/2015 02:55 PM, Wei Liu wrote:
> >On Mon, Oct 05, 2015 at 12:55:00PM +0100, Ian Campbell wrote:
> >>On Mon, 2015-10-05 at 13:51 +0200, Juergen Gross wrote:
> >>>On 10/05/2015 01:44 PM, Ian Campbell wrote:
> On Mon, 2015-10
On 05/10/15 15:05, Jan Beulich wrote:
On 05.10.15 at 15:45, wrote:
>> On 05/10/15 14:36, Jan Beulich wrote:
>> On 05.10.15 at 15:18, wrote:
On 02/10/15 05:40, Juergen Gross wrote:
> Use a bit mask for testing of a set bit instead of test_bit in case no
> atomic operation is
>>> On 05.10.15 at 13:27, wrote:
> | This causes discomfort even to me who has been working on the project for
> | almost 3 years. In practice it is not causing too much trouble for me
> | personally, as the committers I work with never use their committer status
> | to trump my decision -- they
Functional change is simply to prepend "$0: ", to change the exit
code for unknown operation and to slightly alter the error message
when no arguments are given.
A few "exit 0" and "exit $rc" remain.
Signed-off-by: Ian Campbell
---
v3: New patch
---
standalone | 42 -
The return code of sg-run-job does not reflect the state of the job,
which is instead written to the database. For the benefit of running
tests in a loop until failure add a command to retrieve the status to
stdout.
Add a get-job-status command to the standalone helper script.
Signed-off-by: Ian
I've addressed the comments from last time which has resulted in 2 new
patches, one to rename cs-adjust-flight's branch option to branch-set (and
which then contains the docs strings fiddling previously in another patch)
and another to switch to using fail.
Otherwise changes are described in the i
Check if the job passed and if not (so status is fail, broken, running
etc) then return an error.
This is convenient for scripting.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
standalone | 5 +
1 file changed, 5 insertions(+)
diff --git a/standalone b/standalone
index ae70c43..3
Also add a doc string and since this op is not a change adjust the doc
comment accordingly.
Signed-off-by: Ian Campbell
---
v3: New patch.
---
cs-adjust-flight | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/cs-adjust-flight b/cs-adjust-flight
index 834e2c8..a94ed5f 10
Currently the remainder of the comnand line is passed after the host=
ident, which allows for other idents to be given, which isn't all that
useful in practice.
Instead arrange that any additional options up to a "--" marker are
passed before host= and anything after are passed after.
Since the o
>>> On 05.10.15 at 16:23, wrote:
> On Mon, Oct 05, 2015 at 04:36:43AM -0600, Jan Beulich wrote:
>> >>> On 03.10.15 at 20:39, wrote:
>> > The elf_init function uses the log callback to report
>> > errors. But it also memsets the whole structure so the
>> > log callback (if set) is wiped out!
>>
>
El 05/09/15 a les 14.39, Bob Liu ha escrit:
> The max number of hardware queues for xen/blkfront is set by parameter
> 'max_queues', while the number xen/blkback supported is notified through
> xenstore("multi-queue-max-queues").
>
> The negotiated number was the smaller one, and was written back
flight 62654 xen-4.6-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/62654/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-amd queued
test-amd64-amd64-xl
>>> On 05.10.15 at 16:26, wrote:
> On Mon, Oct 05, 2015 at 04:46:55AM -0600, Jan Beulich wrote:
>> >>> On 05.10.15 at 10:49, wrote:
>> > On 03/10/15 19:39, Konrad Rzeszutek Wilk wrote:
>> >> I get compile warnings telling me that
>> >>s->connections[i].fd == fd
>> >>
>> >> 'i' may be past the
1 - 100 of 210 matches
Mail list logo
