From: Vijaya Kumar K
For arm memory for 1024 irq descriptors are allocated
statically irrespective of number of interrupt supported
by the platform.
With this patch, irq descriptors are allocated at run time
and managed using red-black tree. Functions to insert, search
and delete irq descriptor
On 19/02/15 11:31 am, Julien Grall wrote:
On 19/02/2015 02:55, Manish wrote:
On 18/02/15 11:52 pm, Julien Grall wrote:
On 18/02/2015 17:30, Jaggi, Manish wrote:
[manish] There are general comments on the data structures
(a) I don't see a use case where for same domain (VM) there would be
On 19/02/2015 02:55, Manish wrote:
On 18/02/15 11:52 pm, Julien Grall wrote:
On 18/02/2015 17:30, Jaggi, Manish wrote:
[manish] There are general comments on the data structures
(a) I don't see a use case where for same domain (VM) there would be
different context banks , so linked list ma
On 19/02/15 1:43 am, Suravee Suthikulanit wrote:
On 2/18/2015 6:48 AM, Julien Grall wrote:
Hi Suravee,
On 18/02/2015 05:28, Suravee Suthikulanit wrote:
Actually, that seems to be more related to the PCI pass-through
devices.
Isn't the Cavium guys already done that work to support their PCI
flight 34737 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xend 5 xen-build fail REGR. vs. 34151
build-amd64-xend
On 18/02/15 11:52 pm, Julien Grall wrote:
On 18/02/2015 17:30, Jaggi, Manish wrote:
[manish] There are general comments on the data structures
(a) I don't see a use case where for same domain (VM) there would be
different context banks , so linked list may not be required.
I guess you mean
flight 34670 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34670/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build fail REGR. vs. 26303
Regressions which are
flight 34692 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34692/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 34190
build-i386
On 02/19/2015 01:05 AM, Christoph Hellwig wrote:
> On Sun, Feb 15, 2015 at 04:18:58PM +0800, Bob Liu wrote:
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index 3589436..5a90a51 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@
On 02/19/2015 02:22 AM, Felipe Franciosi wrote:
>
>
>> -Original Message-
>> From: Bob Liu [mailto:bob@oracle.com]
>> Sent: 15 February 2015 08:19
>> To: xen-devel@lists.xen.org
>> Cc: David Vrabel; linux-ker...@vger.kernel.org; Roger Pau Monne;
>> konrad.w...@oracle.com; Felipe Fran
On 02/19/2015 02:08 AM, Felipe Franciosi wrote:
>> -Original Message-
>> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> Sent: 18 February 2015 17:38
>> To: Roger Pau Monne
>> Cc: Bob Liu; xen-devel@lists.xen.org; David Vrabel; linux-
>> ker...@vger.kernel.org; Felipe Franc
branch xen-4.4-testing
xen branch xen-4.4-testing
job build-i386-xend
test xen-build
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-4.4-testing.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
flight 34668 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34668/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 13 guest-destroy fail REGR. vs. 34580
Regressions which are reg
branch xen-4.3-testing
xen branch xen-4.3-testing
job build-amd64
test xen-build
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
B
I know this may not be the right question for this forum, but I am looking
if anyone has done this conversion before.
I am trying to find if there is any tried and tested way to convert Citrix
xenserver .xva file to vanilla xen .img file?
Tried "qemu-img convert -O raw" option but that didnt work
* Juergen Gross wrote:
> *Ping*
>
> David wants a comment from the x86 maintainers.
Well, I guess the 'xen: ...' title made us all to skip it
and then it was all just shouting at us within a Xen thread
we never read? :-)
You could change the title to something more exciting next
time aroun
* Juergen Gross wrote:
> Today there are several places in the kernel which build tables
> containing one entry for each possible Xen hypercall. Create an
> infrastructure to be able to generate these tables at build time.
>
> Based-on-patch-by: Jan Beulich
> Signed-off-by: Juergen Gross
> Re
flight 34662 linux-3.16 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34662/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 15 guest-localmigrate/x10fail REGR. vs. 34167
test-amd64-i386-pair 1
On 18/02/2015 11:38 PM, Ian Campbell wrote:
> On Mon, 2015-02-09 at 20:36 +1100, Steven Haigh wrote:
>>> This sounds like a packaging issue -- Debian's packages for example jump
>>> through some hoops to make sure multiple tools packages can be installed
>>> in parallel and the correct ones selecte
>> >> >> >> user will then be able to read / select / enable XEN_PV.,
> >> >> >> >> XEN_PVHVM,
> >> >> >> >> XEN_PVH. Right now they'd only be able to select XEN_PV and/or
> >> >> >> >
XEN_PVHVM is implicit.
>> >> >> >
>> >> >> >
>> >> >> > I think making XEN_PVHVM user selectable is okay.
>> >> >>
>> >> >> OK I'll enable this then.
>> >> >
>> >> &g
select XEN_PV and/or
> >> >> >> XEN_PVH, XEN_PVHVM is implicit.
> >> >> >
> >> >> >
> >> >> > I think making XEN_PVHVM user selectable is okay.
> >> >>
> >> >> OK I'll enable this then.
gt;> >> OK I'll enable this then.
>> >
>> > Please don't. We had bugs in the past because distros did not select
>> > it (they made it an module) and the PV drivers were not loaded.
>>
>> Oy vey.
>>
>> > There should be an history in the git tree behind the desire to make
>> > it non selectable.
>>
>> OK how about we enable the user selection only under CONFIG_EXPERT,
>> otherwise make it hidden.
>
> The CONFIG_EXPERT is gone from the kernel..
I see it as of next-20150218, is there a proposal to remove it?
Luis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Wed, Feb 18, 2015 at 12:01:43PM -0800, Luis R. Rodriguez wrote:
> On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk
> wrote:
> > On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote:
> >> On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross wrote:
> >> > On 02/17/2015 01:25 AM, L
On 2/18/2015 6:48 AM, Julien Grall wrote:
Hi Suravee,
On 18/02/2015 05:28, Suravee Suthikulanit wrote:
Actually, that seems to be more related to the PCI pass-through devices.
Isn't the Cavium guys already done that work to support their PCI device
pass-through?
They were working on it, but
On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote:
>> On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross wrote:
>> > On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote:
>> >>
>> >> On Mon, Feb 16, 2015 at 4:20 PM, Luis R.
On Wed, Feb 18, 2015 at 2:12 AM, Juergen Gross wrote:
> On 02/18/2015 11:03 AM, David Vrabel wrote:
>>
>> On 17/02/15 07:39, Juergen Gross wrote:
>>>
>>>
>>> If we have neither XEN_PV nor XEN_PVH set, why do we have to build
>>> enlighten.c? It will never be used. Same should apply to several othe
This implementation of writev_exact() will cope with an iovcnt greater than
IOV_MAX because glibc will actually let this work anyway, and it is very
useful not to have to work about this in the caller of writev_exact(). The
caller is still required to ensure that the sum of iov_len's doesn't overf
> > > AFAICT you seem to have a list of persistent grants, indirect pages
> > > and a grant table callback for each ring, isn't this supposed to be
> > > shared between all rings?
> > >
> > > I don't think we should be going down that route, or else we can hoard
> > > a large amount of memory and g
> -Original Message-
> From: Bob Liu [mailto:bob@oracle.com]
> Sent: 15 February 2015 08:19
> To: xen-devel@lists.xen.org
> Cc: David Vrabel; linux-ker...@vger.kernel.org; Roger Pau Monne;
> konrad.w...@oracle.com; Felipe Franciosi; ax...@fb.com; h...@infradead.org;
> avanzini.aria...
On 18/02/2015 17:30, Jaggi, Manish wrote:
[manish] There are general comments on the data structures
(a) I don't see a use case where for same domain (VM) there would be different
context banks , so linked list may not be required.
I guess you mean the list in arm_smmu_xen_domain? All the de
On 18/02/15 17:03, Don Slutz wrote:
> On 02/17/15 09:38, Andrew Cooper wrote:
>> On 16/02/15 23:05, Don Slutz wrote:
>>> Summary is that VMware treats "in (%dx),%eax" (or "out %eax,(%dx)")
>>> to port 0x5658 specially. Note: since many operations return data
>>> in EAX, "in (%dx),%eax" is the one
> +int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
> +{
> +int rc;
> +
> +rc = xsm_vm_event_control(XSM_PRIV, d, vec->mode, vec->op);
> +if ( rc )
> +return rc;
>
The XSM check here has the wrong variable name and has been fixed - I seem
to have rushed a
On Tue, Feb 17, 2015 at 02:14:20PM +, Andrew Cooper wrote:
> On 17/02/15 13:39, Jan Beulich wrote:
> On 17.02.15 at 14:32, wrote:
> >> On 17/02/15 12:36, Jan Beulich wrote:
> >> On 14.02.15 at 00:21, wrote:
> On Fri, Feb 13, 2015 at 10:09:39PM +, Andrew Cooper wrote:
> >
On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote:
> On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross wrote:
> > On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote:
> >>
> >> On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez
> >> wrote:
> >>>
> >>> As it is per our agreed upon change
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 18 February 2015 17:38
> To: Roger Pau Monne
> Cc: Bob Liu; xen-devel@lists.xen.org; David Vrabel; linux-
> ker...@vger.kernel.org; Felipe Franciosi; ax...@fb.com; h...@infradead.org;
> avanzini.aria.
On Wed, Feb 18, 2015 at 07:55:16AM +, Jan Beulich wrote:
> >>> On 17.02.15 at 19:25, wrote:
> > On Tue, Feb 17, 2015 at 12:33:12PM +, Jan Beulich wrote:
> >> For all further changes done here, I'd really like to first understand
> >> why you don't simply add extra RMRRs based on the comman
Am 18.02.15 um 16:24 schrieb Ian Campbell:
create ^
thanks
On Thu, 2015-02-12 at 20:47 +0100, Atom2 wrote:
Hi guys,
I am forwarding this message after initially having confirmed with Ian
Campbell on the user list that there's really an issue - please see
further below.
I am currently running x
On Wed, Feb 18, 2015 at 06:28:49PM +0100, Roger Pau Monné wrote:
> El 15/02/15 a les 9.18, Bob Liu ha escrit:
> > A ring is the representation of a hardware queue, this patch separate ring
> > information from blkfront_info to an new struct blkfront_ring_info to make
> > preparation for real multi
Hi Ian,
On 02/02/2015 15:09, Ian Campbell wrote:
On Thu, 2015-01-29 at 15:51 +, Julien Grall wrote:
- Move the retry after looking for first/end. I keep the goto
rather than a loop because it's more clear that we retry because
we were unable to set the bit
Then
> > > static int __init
> > > +setup_io_tlb_segsize(char *str)
> > > +{
> > > + get_option(&str, &io_tlb_segsize);
> > > + return 0;
> > > +}
> > > +__setup("io_tlb_segsize=", setup_io_tlb_segsize);
> >
> > This should be folded in swiotlb=XYZ parsing please.
> >
> I am not very clear about this
El 15/02/15 a les 9.18, Bob Liu ha escrit:
> A ring is the representation of a hardware queue, this patch separate ring
> information from blkfront_info to an new struct blkfront_ring_info to make
> preparation for real multi hardware queues supporting.
>
> Signed-off-by: Arianna Avanzini
> Signe
On 18/02/15 17:01, Ian Campbell wrote:
> Dump the register state before panicing so we have some clue where the
> issue occurred. Also decode the ESR register a bit to save having to
> grab a pen and paper.
>
> ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as
> we already do co
___
From: Julien Grall
Sent: Wednesday, February 18, 2015 5:24 PM
To: Jaggi, Manish; xen-de...@lists.xenproject.org >> xen-devel
Cc: ian.campb...@citrix.com; t...@xen.org; stefano.stabell...@citrix.com;
Jaggi, Manish
Subject: Re: [PATCH for 4.6 13/13] xen/iommu
On Wed, Feb 18, 2015 at 4:55 PM, Tamas K Lengyel
wrote:
> On Wed, Feb 18, 2015 at 2:35 PM, Jan Beulich wrote:
> On 18.02.15 at 13:21, wrote:
>>> On Wed Feb 18 2015 10:46:02 AM CET, Jan Beulich wrote:
>>>
> > > On 18.02.15 at 01:11, wrote:
> diff --git a/xen/common/mem_event.c b/x
Dump the register state before panicing so we have some clue where the
issue occurred. Also decode the ESR register a bit to save having to
grab a pen and paper.
ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as
we already do correctly in the main trap handler.
While here noti
On Sun, Feb 15, 2015 at 04:18:58PM +0800, Bob Liu wrote:
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 3589436..5a90a51 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -614,25 +614,28 @@ static int blk_mq_queue_rq(struct blk
On 02/17/15 09:38, Andrew Cooper wrote:
On 16/02/15 23:05, Don Slutz wrote:
Summary is that VMware treats "in (%dx),%eax" (or "out %eax,(%dx)")
to port 0x5658 specially. Note: since many operations return data
in EAX, "in (%dx),%eax" is the one to use. The other lengths like
"in (%dx),%al" wil
On Sun, Feb 15, 2015 at 04:18:55PM +0800, Bob Liu wrote:
> History:
> It's based on the result of Arianna's internship for GNOME's Outreach Program
> for Women, in which she was mentored by Konrad Rzeszutek Wilk. I also worked
> on
> this patchset with her at that time, and now fully take over thi
On 02/17/2015 02:02 AM, Juergen Gross wrote:
When a xen domain is being restored the LUN state of a pvscsi device
is "Connected" and not "Initialising" as in case of attaching a new
pvscsi LUN.
This must be taken into account when adding a new pvscsi device for
a domain as otherwise the pvscsi L
On Sun, Feb 15, 2015 at 04:18:57PM +0800, Bob Liu wrote:
> As Christoph suggested, remove the legacy support similar to most
> drivers coverted (virtio, mtip, and nvme).
Please merge this into the previous patch.
___
Xen-devel mailing list
Xen-devel@lis
From: Ross Lagerwall
Previously, adding more than 1000 bytes of data would cause a segfault.
Now, the maximum amount of data that can be added is limited by maxsz.
Signed-off-by: Ross Lagerwall
Signed-off-by: Andrew Cooper
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
---
tools/libxl/libxl_
From: Ross Lagerwall
Add a parameter, maxread, to limit the amount of data read from the
source fd of a datacopier.
Signed-off-by: Ross Lagerwall
Signed-off-by: Andrew Cooper
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
---
tools/libxl/libxl_aoutils.c| 11 +++
tools/libxl/lib
This is the same set used by libxc.
Signed-off-by: Andrew Cooper
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
---
tools/libxl/libxl_internal.h | 16
1 file changed, 16 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 934465a..a2b
From: Wen Congyang
datacopier is to read some data and write it out. If we
have some data to send it over network, we cannot use
datacopier. Update it to support this case.
Signed-off-by: Wen Congyang
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
---
tools/libxl/libxl_aoutils.c |8 +-
From: Ross Lagerwall
Implement a read-only mode for libxl__datacopier. The mode is invoked
when readbuf is set and writefd is < 0. On success, the callback passes
the number of bytes read.
Signed-off-by: Ross Lagerwall
Signed-off-by: Andrew Cooper
CC: Ian Campbell
CC: Ian Jackson
CC: Wei L
POLLIN|POLLHUP is a valid revent to recieve from poll() when the far end has
hung up, but data is still available to be read.
Currently all POLLHUPs are fatal. This is a problem when using the legacy
stream conversion script which will exit 0 when it has completed its task and
has left valid data
To support migration v2, we need far more flexibility out of the datacopier.
This series adds the ability to read from an fd into a local buffer and to
copy a specific number of bytes rather than to EOF. It also contains bugfixes
related to writing from a local buffer, and POLLHUP handling.
Andr
This patch introduces two new buildjobs:
build--freebsd-xen: sets up a FreeBSD host and builds Xen.
build--freebsd-freebsd: sets up a FreeBSD host and builds FreeBSD sets
and a mfsBSD installer image.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
---
ap-common | 2 ++
mfi-
On Wed, Feb 18, 2015 at 11:01 AM, Ian Campbell wrote:
> On Wed, 2015-02-18 at 10:47 -0500, Jintack Lim wrote:
>> On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell
>> wrote:
>> > Dump the register state before panicing so we have some clue where the
>> > issue occurred. Also decode the ESR register
On Wed, Feb 18, 2015 at 11:00 AM, Julien Grall wrote:
>
> On 18/02/2015 15:47, Jintack Lim wrote:
>>
>> On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell
>> wrote:
>>>
>>> Dump the register state before panicing so we have some clue where the
>>> issue occurred. Also decode the ESR register a bit to
This scripts takes care of installing the run-time dependencies, unpacking
the Xen files and setup the right configuration in order to boot a FreeBSD
PVH Dom0.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
---
ts-xen-install-freebsd | 128 +
El 10/02/15 a les 21.10, Ian Jackson ha escrit:
> In practice, cancelling this task will cause all subsequent actual
> backend operations to fail, but will not actually cause the
> libxl_device_events_handler operation to complete.
>
> Signed-off-by: Ian Jackson
Acked-by: Roger Pau Monné
El 10/02/15 a les 21.09, Ian Jackson ha escrit:
> On the success path, do not call GC_FREE explicitly. Instead, call
> AO_INPROGRESS.
>
> GC_FREE will free the gc underlying the long-term ao, which is then
> subsequently referenced in backend_watch_callback's call to
> libxl__nested_ao_create. I
>>> On 18.02.15 at 16:39, wrote:
> --- a/xen/common/vsprintf.c
> +++ b/xen/common/vsprintf.c
> @@ -269,7 +269,28 @@ static char *pointer(char *str, char *end, const char
> **fmt_ptr,
> {
> const char *fmt = *fmt_ptr, *s;
>
> -/* Custom %p suffixes. See XEN_ROOT/docs/misc/printk-format
Install pkg (the binary package management tool) and the dependencies
needed to build Xen.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
---
Changes since RFC:
- Add the tools necessary in order to build the man pages and
markdown documents.
---
ts-xen-build-prep-freebsd
In order to test FreeBSD HEAD we need to build a mfsBSD installer and
sets based on the version that we want to test. This patch adds support for
building such mfsBSD image and sets.
In order to build the images sources from two different repositories are
needed. The first ones of course are the F
Hello,
The following series enables setting up a FreeBSD PVH Dom0 host. Although
this is marked as "v4" it should clearly have the RFC tag. The flow is based
on the following diagram:
http://xenbits.xen.org/people/royger/osstest_freebsd.jpg
Patch 7 introduces a new management script, mg-freebs
Euan Harris writes ("Re: [RFC PATCH v2 00/29] libxl: Cancelling asynchronous
operations"):
> On Tue, Feb 10, 2015 at 08:09:47PM +, Ian Jackson wrote:
> > I have rebased this onto current staging. I have compiled it but
> > NOT EXECUTED IT AT ALL. Euan, I thought it would be useful to give
>
The output of the FreeBSD buildjob generates several files that are stashed
independently, so check each of them individually.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
---
ts-build-check | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --
This is done using mfsBSD, which can be booted from pxelinux and
contains a script to automatically install FreeBSD using ZFS on root.
After the install the host is set to boot from the local disk.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
---
Changes since RFC:
- Set the
This is needed when bootstrapping FreeBSD, since the installer has ssh
enabled with the root password set to 'root' by default.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
---
Changes since RFC:
- Place the temp filename in a local variable.
- Add error checks.
---
Osstes
This is only used by target_cmd_root and target_putfile_root and will be
needed for mfsBSD which generates new keys on each boot.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
---
Osstest/TestSupport.pm | 25 -
1 file changed, 16 insertions(+), 9 delet
This script allows moving a FreeBSD build (as produced by
ts-freebsd-create-mfsbsd) so it's usable by other test/build jobs.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
---
mg-freebsd-installer-update | 59 +
1 file changed, 59 in
This patch contains a new subroutine that guesses the right make
command to use (gmake on BSDs, make otherwise).
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
---
ts-xen-build | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/ts-xen-build b/ts-
This mimics the behaviour of built_stash.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
---
Osstest/TestSupport.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 0c72faa..4d35a19 100644
--- a/Osstest/TestSupport.pm
++
On 02/18/2015 10:52 AM, Julien Grall wrote:
Hi Boris,
On 18/02/2015 15:39, Boris Ostrovsky wrote:
If invalid pointer (i.e. something smaller than HYPERVISOR_VIRT_START)
is passed for %*ph/%pv/%ps/%pS format specifiers then print value of the
pointer in parentheses.
For example:
struct vcpu
Hi,
On Tue, Feb 10, 2015 at 08:09:47PM +, Ian Jackson wrote:
> I have rebased this onto current staging. I have compiled it but
> NOT EXECUTED IT AT ALL. Euan, I thought it would be useful to give
> you something you could start to work on building against.
>
> I wouldn't recommend testing
On Wed, 2015-02-18 at 09:50 -0600, Rob Herring wrote:
> On Wed, Feb 18, 2015 at 7:51 AM, Julien Grall wrote:
> > From: Ard Biesheuvel
> >
> > This patch registers hvc0 as the preferred console if no console
> > has been specified explicitly on the kernel command line.
> >
> > The purpose is to al
On 18/02/2015 15:47, Jintack Lim wrote:
On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell wrote:
Dump the register state before panicing so we have some clue where the
issue occurred. Also decode the ESR register a bit to save having to
grab a pen and paper.
ESR_EL2 is a 32-bit register, so use
On Wed, 2015-02-18 at 16:00 +, Julien Grall wrote:
> Can you try to get the line of code related to this PC? You could do it
> with addr2line.
>From private mail I know that this machine sees issues under native
Linux too, I suspect a h/w fault so I don't think it is worth diagnosing
further
Hi Boris,
On 18/02/2015 15:39, Boris Ostrovsky wrote:
If invalid pointer (i.e. something smaller than HYPERVISOR_VIRT_START)
is passed for %*ph/%pv/%ps/%pS format specifiers then print value of the
pointer in parentheses.
For example:
struct vcpu *v0 = NULL;
struct vcpu *v1 = (void *)0xffU
On Wed, 2015-02-18 at 10:47 -0500, Jintack Lim wrote:
> On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell
> wrote:
> > Dump the register state before panicing so we have some clue where the
> > issue occurred. Also decode the ESR register a bit to save having to
> > grab a pen and paper.
> >
> > ESR
On Wed, Feb 18, 2015 at 2:35 PM, Jan Beulich wrote:
On 18.02.15 at 13:21, wrote:
>> On Wed Feb 18 2015 10:46:02 AM CET, Jan Beulich wrote:
>>
>>> > > > On 18.02.15 at 01:11, wrote:
>>> > diff --git a/xen/common/mem_event.c b/xen/common/vm_event.c
>>> > similarity index 59%
>>> > rename fro
On Wed, Feb 18, 2015 at 7:51 AM, Julien Grall wrote:
> From: Ard Biesheuvel
>
> This patch registers hvc0 as the preferred console if no console
> has been specified explicitly on the kernel command line.
>
> The purpose is to allow platform agnostic kernels and boot images
> (such as distro inst
On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell wrote:
> Dump the register state before panicing so we have some clue where the
> issue occurred. Also decode the ESR register a bit to save having to
> grab a pen and paper.
>
> ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as
>
On Wed, 2015-02-18 at 15:31 +, Julien Grall wrote:
> > Either soc has a device_type property which we understand, in which case
> > we would handle it and stop recursing or (more likely for an soc) it
> > does not, in which case we would handle the pcie ranges property, but it
> > needs to be
Hi Ian,
On 18/02/2015 15:19, Ian Campbell wrote:
diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
index 1693b5d..89b8eb3 100644
--- a/xen/arch/arm/arm64/traps.c
+++ b/xen/arch/arm/arm64/traps.c
@@ -24,11 +24,6 @@
#include
-asmlinkage void do_trap_serror(struct cpu_user_r
On 18/02/15 15:39, Boris Ostrovsky wrote:
> If invalid pointer (i.e. something smaller than HYPERVISOR_VIRT_START)
> is passed for %*ph/%pv/%ps/%pS format specifiers then print value of the
> pointer in parentheses.
>
> For example:
>
> struct vcpu *v0 = NULL;
> struct vcpu *v1 = (void *)0xffUL;
If invalid pointer (i.e. something smaller than HYPERVISOR_VIRT_START)
is passed for %*ph/%pv/%ps/%pS format specifiers then print value of the
pointer in parentheses.
For example:
struct vcpu *v0 = NULL;
struct vcpu *v1 = (void *)0xffUL;
unsigned val = 0xab;
unsigned *ptr = &val;
unsigned *
On 18/02/2015 15:18, Ian Campbell wrote:
On Wed, 2015-02-18 at 15:05 +, Julien Grall wrote:
On 18/02/2015 14:37, Ian Campbell wrote:
On Wed, 2015-02-18 at 14:19 +, Julien Grall wrote:
I think so, and we probably should consider the two cases separately
since the right answer could re
Processing commands for x...@bugs.xenproject.org:
> create ^
Created new bug #49 rooted at `<54dd036e.4060...@web2web.at>'
Title: `Re: BUG - xen-netback stats interface limited to 32-bit values on 64
bit systems'
> thanks
Finished processing.
Modified/created Bugs:
- 49: http://bugs.xenproject.
On Wed, 2015-02-18 at 13:51 +, Julien Grall wrote:
> From: Ard Biesheuvel
>
> This patch registers hvc0 as the preferred console if no console
> has been specified explicitly on the kernel command line.
>
> The purpose is to allow platform agnostic kernels and boot images
> (such as distro i
create ^
thanks
On Thu, 2015-02-12 at 20:47 +0100, Atom2 wrote:
> Hi guys,
> I am forwarding this message after initially having confirmed with Ian
> Campbell on the user list that there's really an issue - please see
> further below.
>
> I am currently running xen-4.3.3 on gentoo (dom0 is base
flight 34656 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34656/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs.
33480
test-amd64-i38
On Wed, 2015-02-18 at 15:13 +, Julien Grall wrote:
>
> On 18/02/2015 14:37, Ian Campbell wrote:
> > I am reasonably convinced that for MMIO (+IO+CFG space) we should map
> > everything as described by the ranges property of the top most node, it
> > can be considered an analogue to / extension
Dump the register state before panicing so we have some clue where the
issue occurred. Also decode the ESR register a bit to save having to
grab a pen and paper.
ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as
we already do correctly in the main trap handler.
While here noti
On Wed, 2015-02-18 at 15:05 +, Julien Grall wrote:
>
> On 18/02/2015 14:37, Ian Campbell wrote:
> > On Wed, 2015-02-18 at 14:19 +, Julien Grall wrote:
> > I think so, and we probably should consider the two cases separately
> > since the right answer could reasonably differ for different r
On 18/02/2015 15:05, Julien Grall wrote:
On 18/02/2015 14:37, Ian Campbell wrote:
On Wed, 2015-02-18 at 14:19 +, Julien Grall wrote:
I think so, and we probably should consider the two cases separately
since the right answer could reasonably differ for different resource
types.
I am rea
On 18/02/2015 14:37, Ian Campbell wrote:
I am reasonably convinced that for MMIO (+IO+CFG space) we should map
everything as described by the ranges property of the top most node, it
can be considered an analogue to / extension of the reg property of that
node.
BTW, the CFG space is part of t
1 - 100 of 189 matches
Mail list logo
