The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Slaby jsl...@suse.cz
Cc: David Vrabel david.vra...@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc
chunk). That would require more care when we fail to expand the
event channel.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
---
drivers/xen/events
will have
to split the Linux page in 4K chunk before asking Xen to add/remove the
frame from the guest.
Note that this can work on any page granularity assuming it's a multiple
of 4K.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris
The xenstore ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
---
drivers/xen/xenbus/xenbus_probe.c | 4
to allocate
dynamically. We can expand the current region to support up to 16/128 vCPUs.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
purpose.
If someone wants to change the guest layout, he will know that the
re-dist region will be this size.
I would also like to keep the BUILD_BUG_ON in vgic-v3 in order to check
if there is enough space reserved in the guest layout for the re-dist
(see your patch #2).
Regards,
--
Julien
On 14/05/15 18:48, Julien Grall wrote:
Although you would need to reshuffle a bit the layout. With your
solution, if the guest is using 128 vCPUs it will overlap the
grant-table region, magic page (xenstore, xenconsole,...) and the
beginning of the RAM. whoops ;).
Hmmm... forget
on the grant table code.
Note that we allocate a Linux page for each rx skb but only the first
4KB is used. We may improve the memory usage by extending the size of
the rx skb.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky
With 64KB page granularity support in Linux, a page will be split accross
multiple MFN (Xen is using 4KB page granularity). Thoses MFNs may not be
contiguous.
With the offset in the page, the helper will be able to know which MFN
the driver needs to retrieve.
Signed-off-by: Julien Grall
definition. They have exactly the same name but prefixed with
XEN_/xen_ prefix.
Also modify page_to_pfn to use new Xen page definition.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David
to only bump to 16 vCPUs for now.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
From: Julien Grall julien.gr...@linaro.org
Make the code less confusing to read now that Linux may not have the
same page size as Xen.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Roger Pau Monné roger@citrix.com
---
drivers/block
Using xen/page.h will be necessary later for using common xen page
helpers.
As xen/page.h already include asm/xen/page.h, always use the later.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc
rx-status is an int16_t, print it using %d rather than %u in order to
have a meaningful value when the field is negative.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra
Julien Grall (23):
xen: Include xen/page.h rather than asm/xen/page.h
xen/xenbus: client: Fix call of virt_to_mfn in xenbus_grant_ring
xen/grant-table: Remove unused macro SPP
block/xen-blkfront: Remove unused macro MAXIMUM_OUTSTANDING_BLOCK_REQS
block/xen-blkfront: Remove invalid comment
The variables old_req_cons and ring_slots_used are assigned but never
used since commit 1650d5455bd2dc6b5ee134bd6fc1a3236c266b5b xen-netback:
always fully coalesce guest Rx packets.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l
don't use it later.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
---
drivers/xen/xenbus/xenbus_client.c | 6 +++---
1 file
From: Julien Grall julien.gr...@linaro.org
Since commit b764915 xen-blkfront: use a different scatterlist for each
request, biovec has been replaced by scatterlist when copying back the
data during a completion request.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek
From: Julien Grall julien.gr...@linaro.org
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Roger Pau Monné roger@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
---
drivers/block/xen
SPP was used by the grant table v2 code which has been removed in
commit 438b33c7145ca8a5131a30c36d8f59bce119a19a xen/grant-table:
remove support for V2 tables.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov
From: Julien Grall julien.gr...@linaro.org
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
arch/arm/include/asm/xen/page.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen
*/
-BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE)
MAX_VIRT_CPUS);
I'd like to keep this BUILD_BUG_ON. It ensures that we reserved enough
space in the guest layout for the redistributors.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen
From: Julien Grall julien.gr...@linaro.org
On ARM, every non-PCI device are described in the device tree. Each of
them can be found via a path.
This patch introduces a very basic support, only the IOMMU will be set
up correctly. The user will have to:
- Describe the device in the partial
From: Julien Grall julien.gr...@linaro.org
The functions fdt_{first,next}_subnode may not be available because:
* It has been introduced in 2013 = Doesn't work on Wheezy
* The prototype exists but the functions are not exposed. Don't ask
why...
The later has been fixed recently
From: Julien Grall julien.gr...@linaro.org
Allow the user to pass additional nodes to the guest device tree. For
this purpose, everything in the node /passthrough from the partial
device tree will be copied into the guest device tree.
The node /aliases will be also copied to allow the user
From: Julien Grall julien.gr...@linaro.org
Note that the example is done on Midway whose SMMU driver is not
supported on Xen upstream.
Currently, I don't have other platform where I can test Device Tree
passthrough.
Signed-off-by: Julien Grall julien.gr...@linaro.org
Acked-by: Ian Campbell
From: Julien Grall julien.gr...@linaro.org
The option dtdev will be used to passthrough a device described
in the device tree to a guest.
Signed-off-by: Julien Grall julien.gr...@linaro.org
Acked-by: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Wei Liu wei.l
From: Julien Grall julien.gr...@linaro.org
The partial device tree may contains phandle. The Device Tree Compiler
tends to allocate the phandle from 1.
Reserve the ID 65000 for the GIC phandle. I think we can safely assume
that the partial device tree will never contain a such ID.
Signed-off
: josh.whiteh...@dornerworks.com
Julien Grall (6):
tools/libxl: Check if fdt_{first,next}_subnode are present in libfdt
tools/(lib)xl: Add partial device tree support for ARM
tools/libxl: arm: Use an higher value for the GIC phandle
libxl: Add support for Device Tree passthrough
xl: Add new
Hi Wei,
Thanks you for the review.
On 15/05/15 03:35, Wei Liu wrote:
On Thu, May 14, 2015 at 06:01:01PM +0100, Julien Grall wrote:
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity working as a
network backend
,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
there is a mismatch.
Which brings to the solution with one vITS.
As said your event channel paragraph, we should put aside the event
channel injected by the vITS for now. It was only a suggestion and it
will require more though that the vITS emulation.
--
Julien Grall
not have any significance.
The SYNC command ensure that any commands before it has been completed...
The guest can decide to put one after only one command or after a batch
of command.
You have to respect it and not let Xen guess when it's necessary to have
one.
Regards,
--
Julien Grall
On 15/05/15 14:24, Ian Campbell wrote:
On Fri, 2015-05-15 at 18:44 +0530, Vijay Kilari wrote:
On Fri, May 15, 2015 at 6:23 PM, Ian Campbell ian.campb...@citrix.com
wrote:
On Fri, 2015-05-15 at 18:17 +0530, Vijay Kilari wrote:
On Fri, May 15, 2015 at 5:33 PM, Julien Grall julien.gr
the emulation.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
.
AFAICT, cavium can be shipped with 1 or 2 nodes. This will result to
have 1 or 2 ITS.
Migration wouldn't be possible between servers using different number of
nodes.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http
On 15/05/15 15:04, Vijay Kilari wrote:
On Fri, May 15, 2015 at 7:14 PM, Julien Grall julien.gr...@citrix.com wrote:
On 15/05/15 14:24, Ian Campbell wrote:
On Fri, 2015-05-15 at 18:44 +0530, Vijay Kilari wrote:
On Fri, May 15, 2015 at 6:23 PM, Ian Campbell ian.campb...@citrix.com
wrote
Signed-off-by: Julien Grall julien.gr...@citrix.com
---
xen/arch/arm/gic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index f023e4f..125298c 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -182,7 +182,7 @@ int
is fragile and cause performance regression.
Given that firmware is available for people having the board, I think
we can request the user to upgrade to the latest version.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Pranavkumar Sawargaonkar pranavku...@linaro.org
---
Ref: http
is
+assigned the label Bsystem_u:system_r:domU_t, which is defined in
+the default policy.
It's not easy to know that seclabel will be stored in ssid_label.
It would be good to have this explanation into the toolstack API.
Regards,
--
Julien Grall
Hi,
On 16/05/2015 05:03, Vijay Kilari wrote:
On Fri, May 15, 2015 at 11:01 PM, Julien Grall julien.gr...@citrix.com wrote:
On 15/05/15 16:38, Ian Campbell wrote:
On Fri, 2015-05-15 at 16:05 +0100, Julien Grall wrote:
On 15/05/15 15:04, Vijay Kilari wrote:
On Fri, May 15, 2015 at 7:14 PM
,
+(long long unsigned int)p-base_address, p-region_size);
Ditto missing KERN_INFO PREFIX
+}
+break;
+
default:
printk(KERN_WARNING PREFIX
Found unsupported MADT entry (type = %#x)\n,
Regards,
--
Julien Grall
different,
comment...). Can you update it?
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
acpi_os_map_memory from acpi_os_map_iomem. I would rename to something
more meaningful such as arch_acpi_os_map_memory.
Although, given that acpi_os_map_memory only call acpi_os_map_iomem. I
would move acpi_os_map_memory per-architecture. FWIW, it's what Linux does.
--
Julien Grall
notice that the patch (see 9eb1105) is slightly different.
Mostly documenting the ACPI version for the fields.
Can you update the patch based on Linux code to use the latest version
(i.e the version upstreamed)?
Regards,
--
Julien Grall
___
Xen-devel
.
+{
+return acpi_gbl_FADT.arm_boot_flags ACPI_FADT_PSCI_USE_HVC;
+}
Regards,
--
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
as well as with what is to live in os.c.
Sorry, I had in mind an older version of the ACPI series for Linux. I
forgot to check what was really done.
Although, acpi_os_map_iomem is also part of the ACPI CA. Would a
function arch_acpi_os_map_memory suit for you?
Regards,
--
Julien Grall
implementation of acpi_os_map_iomem is not valid on ARM:
the first MB is not always mapped and we already have mapped the table
if it lives in RAM.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hi Wei,
On 15/05/15 16:31, Wei Liu wrote:
On Fri, May 15, 2015 at 01:35:42PM +0100, Julien Grall wrote:
On 15/05/15 03:35, Wei Liu wrote:
On Thu, May 14, 2015 at 06:01:01PM +0100, Julien Grall wrote:
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow
Hi David,
On 15/05/15 16:45, David Vrabel wrote:
On 14/05/15 18:00, Julien Grall wrote:
Hi all,
ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
hypercall interface and PV protocol are always based on 4KB page granularity.
Any attempt to boot a Linux guest
it (disable_acpi, acpi parameters...) in a common place.
+#endif /*_ASM_ARM_ACPI_H*/
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
();
+
vm_init();
dt_unflatten_host_device_tree();
Regards,
[1]
http://lists.xenproject.org/archives/html/xen-devel/2015-02/msg01152.html
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Reviewed-by: Julien Grall julien.gr...@citrix.com
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
interface is present
runtime services are also available.
Thanks for the explanation. Please add it in the next cover letter. It's
useful for people who weren't present at the meeting or forgot what was
said.
Regards,
--
Julien Grall
___
Xen-devel
Hi Ian,
On 13/05/15 15:07, Ian Campbell wrote:
On Tue, 2015-05-12 at 15:33 +0100, Julien Grall wrote:
From: Julien Grall julien.gr...@linaro.org
The functions fdt_{fisrt,next}_subnode may not be available because:
first
* It has been introduced in 2013 = Doesn't work on Wheezy
Hi Ian,
On 13/05/15 16:39, Ian Campbell wrote:
On Wed, 2015-05-13 at 16:22 +0100, Julien Grall wrote:
:(. Both the distribution are using an old version of libfdt where the 3
prototypes are defined but the implementation is not exposed in the
library (this is because they use a whitelist
the warning only says
suspend/resume won't work. Not the kernel will crash.
Although, we know that DT is often tight to the kernel version. So I'm
not sure if we should care of it.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http
assignment
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
still argue that it is the right approach
to take proper care of it, thus;
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hi,
On 13/05/2015 19:33, Julien Grall wrote:
+#ifndef LIBXL_LIBFDT_COMPAT_H
+#define LIBXL_LIBFDT_COMPAT_H
+
+#if !HAVE_DECL_FDT_FIRST_SUBNODE
+int fdt_first_subnode(const void *fdt, int offset);
+#endif
+
+#if !HAVE_DECL_FDT_NEXT_SUBNODE
+int fdt_next_subnode(const void *fdt, int offset
LIBXL_LIBFDT_COMPAT_H
#if !HAVE_DECL_FDT_FIRST_SUBNODE
int fdt_first_subnode(const void *fdt, int offset);
#endif
#if !HAVE_DECL_FDT_NEXT_SUBNODE
int fdt_next_subnode(const void *fdt, int offset);
#endif
#endif
/*
* Local variables:
* mode: C
* c-basic-offset: 4
* indent-tabs-mode: nil
* End:
*/
--
Julien
From: Julien Grall julien.gr...@linaro.org
The option dtdev will be used to passthrough a device described
in the device tree to a guest.
Signed-off-by: Julien Grall julien.gr...@linaro.org
Acked-by: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Wei Liu wei.l
From: Julien Grall julien.gr...@linaro.org
On ARM, every non-PCI device are described in the device tree. Each of
them can be found via a path.
This patch introduces a very basic support, only the IOMMU will be set
up correctly. The user will have to:
- Describe the device in the partial
From: Julien Grall julien.gr...@linaro.org
The partial device tree may contains phandle. The Device Tree Compiler
tends to allocate the phandle from 1.
Reserve the ID 65000 for the GIC phandle. I think we can safely assume
that the partial device tree will never contain a such ID.
Signed-off
Hello all,
This a resend of the last part of non-PCI passthrough after Andrii spotted
that I forgot to include the new header libxl_libfdt_compat.h.
I hope this will be the last build error found.
Regards,
Cc: Andrii Anisov andrii.ani...@globallogic.com
Julien Grall (6):
tools/libxl: Check
From: Julien Grall julien.gr...@linaro.org
Allow the user to pass additional nodes to the guest device tree. For
this purpose, everything in the node /passthrough from the partial
device tree will be copied into the guest device tree.
The node /aliases will be also copied to allow the user
From: Julien Grall julien.gr...@linaro.org
The functions fdt_{fisrt,next}_subnode may not be available because:
* It has been introduced in 2013 = Doesn't work on Wheezy
* The prototype exists but the functions are not exposed. Don't ask
why...
The later has been fixed recently
From: Julien Grall julien.gr...@linaro.org
Note that the example is done on Midway whose SMMU driver is not
supported on Xen upstream.
Currently, I don't have other platform where I can test Device Tree
passthrough.
Signed-off-by: Julien Grall julien.gr...@linaro.org
Acked-by: Ian Campbell
On 12/05/15 13:53, Ian Campbell wrote:
On Tue, 2015-05-12 at 13:35 +0100, Julien Grall wrote:
On 12/05/15 11:07, Ian Campbell wrote:
On Mon, 2015-05-11 at 18:09 +, osstest service user wrote:
flight 55255 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/55255
a bit more? What is missing?
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
didn't see any answer from
him.
I pinged him last friday.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 15/05/15 16:38, Ian Campbell wrote:
On Fri, 2015-05-15 at 16:05 +0100, Julien Grall wrote:
On 15/05/15 15:04, Vijay Kilari wrote:
On Fri, May 15, 2015 at 7:14 PM, Julien Grall julien.gr...@citrix.com
wrote:
On 15/05/15 14:24, Ian Campbell wrote:
On Fri, 2015-05-15 at 18:44 +0530, Vijay
Hi Zoltan,
On 07/05/2015 13:37, Zoltan Kiss wrote:
On 07/05/15 10:32, Ian Campbell wrote:
On Thu, 2015-05-07 at 09:52 +0100, Zoltan Kiss wrote:
Looks good at first glance, let me try it on a board.
On 06/05/15 19:52, Julien Grall wrote:
[...]
I'm concerned to see a newly driver (pushed
.
It would avoid us to forget the problem when this will be support it later.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hi Ian,
On 15/04/15 15:57, Ian Campbell wrote:
On Wed, 2015-04-08 at 13:23 +0100, Julien Grall wrote:
Hi Chen,
Subject: I think you can drop the _ in spin_table.
On 07/04/15 08:33, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
On arm64, either firmware or xen's smp_up_cpu gate
On 15/04/2015 17:21, Ian Campbell wrote:
On Wed, 2015-04-15 at 16:56 +0100, Julien Grall wrote:
Hi Ian,
On 15/04/15 15:57, Ian Campbell wrote:
On Wed, 2015-04-08 at 13:23 +0100, Julien Grall wrote:
Hi Chen,
Subject: I think you can drop the _ in spin_table.
On 07/04/15 08:33, Chen Baozi
:
arndale: mach-exynos/platsmp.c
omap5: mach-omap2/omap-smp.c
I wasn't able to find if RCAR (CC Iurii for it) and Vexpress really
require an SGI to bring up secondary CPUs.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http
-system-i386
Currently the QEMU built by Xen is installed in a Xen directory (IIRC
/usr/lib/xen/bin). Should not you use a similar path for raisin?
Otherwise you would override the QEMU installed via the distrib package
manager.
I guess this could be done by $INST_DIR?
Regards,
--
Julien
may use a different configuration that the user
wants to use.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hi Ian,
On 16/04/2015 15:39, Ian Campbell wrote:
On Thu, 2015-04-09 at 16:09 +0100, Julien Grall wrote:
From: Julien Grall julien.gr...@linaro.org
Each domain may have a different number of IRQs depending on the devices
assigned to it.
Rather re-using the number of IRQs used
Hi Ian,
On 16/04/2015 15:55, Ian Campbell wrote:
On Thu, 2015-04-09 at 16:09 +0100, Julien Grall wrote:
From: Julien Grall julien.gr...@linaro.org
I've left the XSM related quotes untrimmed and CCd Daniel. I think it's
all code motion (making x86 specific things generic), so perhaps no ack
Hi Ian,
On 16/04/2015 16:11, Ian Campbell wrote:
On Thu, 2015-04-09 at 16:09 +0100, Julien Grall wrote:
From: Julien Grall julien.gr...@linaro.org
A device node is described by a path. It will be used to retrieved the
retrieve
node in the device tree and assign the related device
Hi Ian,
On 16/04/2015 16:40, Ian Campbell wrote:
On Thu, 2015-04-16 at 16:20 +0100, Julien Grall wrote:
Concerning XSM, even if ARM is using one hypercall rather than 2, the
resulting check is nearly the same.
XSM PHYSDEVOP_map_pirq:
1) Check if the current domain can add resource
Hi Ian,
On 16/04/2015 17:53, Ian Campbell wrote:
On Mon, 2015-04-06 at 13:18 +0200, Julien Grall wrote:
Hi Ian,
Subject: s/PCTR/CPTR/
On 31/03/2015 12:07, Ian Campbell wrote:
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 14 ++
1 file
Hi Ian,
On 16/04/2015 17:08, Ian Campbell wrote:
On Thu, 2015-04-02 at 16:09 +0100, Julien Grall wrote:
Hi Ian,
On 31/03/2015 11:07, Ian Campbell wrote:
Signed-off-by: Ian Campbell ian.campb...@citrix.com
xen: arm: Fix handling of ICC_{SGI1R,SGI0R,ASGI1R}_EL1
Having injected an undefined
Hi Ian,
On 16/04/2015 17:34, Ian Campbell wrote:
On Fri, 2015-04-03 at 15:05 +0200, Julien Grall wrote:
Hi Ian,
On 31/03/2015 12:07, Ian Campbell wrote:
Reference the bit which enables the trap and the section/page which
describes what that bit enables.
These ones are pretty trivial
Hi Ian,
On 09/04/15 18:04, Ian Jackson wrote:
Julien Grall writes (Re: [Xen-devel] [PATCH v5 p2 16/19] tools/libxl: arm:
Use an higher value for the GIC phandle):
On 09/04/15 17:52, Ian Jackson wrote:
What would happen if our assumption about the DT compiler were
violated ?
The phandle
,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
BTW, your series is not threaded.
I've already said it on another series. Please look at [1] to see how to
send correctly your series.
[1]
http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_the_patches_to_the_list
Regards,
On 13/04/15 11:19, Julien Grall wrote:
Hi Manish
structure?
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
From: Julien Grall julien.gr...@linaro.org
The maximum size of the copied string has been chosen based on the value
use by XSM in similar case.
Furthermore, Linux seems to allow path up to 4096 characters. Though
this could vary from one OS to another.
Signed-off-by: Julien Grall julien.gr
From: Julien Grall julien.gr...@linaro.org
ARM and x86 use a different hypercall to map an IRQ to a domain.
The hypercall to give IRQ permission to the domain has also been moved
to be an x86 specific function as ARM guest won't be able to manage the IRQ.
We may want to support it later.
Signed
From: Julien Grall julien.gr...@linaro.org
The partial device tree may contains phandle. The Device Tree Compiler
tends to allocate the phandle from 1.
Reserve the ID 65000 for the GIC phandle. I think we can safely assume
that the partial device tree will never contain a such ID.
Signed-off
From: Julien Grall julien.gr...@linaro.org
Xen has to release IRQ routed to a domain in order to reuse later.
Currently only SPIs can be routed to the guest so we only need to
browse SPIs for a specific domain.
Furthermore, a guest can crash and leave the IRQ in an incorrect state
(i.e has
From: Julien Grall julien.gr...@linaro.org
A device node is described by a path. It will be used to retrieved the
node in the device tree and assign the related device to the domain.
Only non-PCI protected by an IOMMU can be assigned to a guest.
Also document the behavior
From: Julien Grall julien.gr...@linaro.org
Currently, when the device is deassigned from a domain, we directly reassign
to DOM0.
As the device may not have been correctly reset, this may lead to corruption or
expose some part of DOM0 memory. Also, we may have no way to reset some
platform
Hi Ian,
On 31/03/15 12:43, Ian Campbell wrote:
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
The partial device tree may contains phandle. The Device Tree Compiler
tends to allocate the phandle from 1.
Reserve the ID 65000 for the GIC phandle. I think we can safely assume
On 09/04/15 17:52, Ian Jackson wrote:
Julien Grall writes (Re: [Xen-devel] [PATCH v5 p2 16/19] tools/libxl: arm:
Use an higher value for the GIC phandle):
On 09/04/15 17:17, Ian Jackson wrote:
I only expect people using the partial device tree in very specific use
case. Generic use case
On 09/04/15 18:00, Julien Grall wrote:
On 09/04/15 17:52, Ian Jackson wrote:
Julien Grall writes (Re: [Xen-devel] [PATCH v5 p2 16/19] tools/libxl: arm:
Use an higher value for the GIC phandle):
On 09/04/15 17:17, Ian Jackson wrote:
I only expect people using the partial device tree in very
From: Julien Grall julien.gr...@linaro.org
The toolstack may not have deassigned every device used by a guest.
Therefore we have to go through the device list and remove them before
asking the IOMMU drivers to release memory for this domain.
This can be done by moving the call to the release
901 - 1000 of 6489 matches
Mail list logo
