flight 34731 xen-4.5-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34731/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass
test-armhf-armhf-xl-sedf 10 mig
Translated address could have an offset applied to them.
Replicate same value for device node to avoid improper address
computation in the OS.
Signed-off-by: Frediano Ziglio
---
xen/arch/arm/gic-v2.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
Submit again after
This set of patches add Xen support for hip04-d01 platform (see
https://wiki.linaro.org/Boards/D01 for details).
Changes from v4:
- rebased to new version;
- removed patch for computing GIC addresses as it apply to all platforms;
- removed patches to platform (cpu and system operations) as now th
The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.
Signed-off-by: Frediano Ziglio
---
xen/arch/arm/gic-v2.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/a
Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.
Signed-off-by: Frediano Ziglio
---
xen/arch/arm/gic-v2.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/
This name can appear in some Linux kernel repos. Not very fortunate,
but to avoid others spending an hour to spot that few characters
difference it worth to work around it.
Signed-off-by: Zoltan Kiss
---
xen/arch/arm/gic-v2.c | 1 +
xen/include/asm-arm/gic.h | 4 +++-
2 files changed, 4 inse
The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.
Use nr_lines to check for maximum irq supported. hip04-d01 support less
interrupts due
On Thu, 2015-02-19 at 18:01 +, Julien Grall wrote:
> Based on the discussion, what about waiting until someone complain about
> GICv3 support on Xen 4.5?
That sounds like a reasonable compromise.
My potential backports list now contains:
xen/arm: Bug fixes for the vGIC
-> 15 patch series, ma
On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
> This is the same set used by libxc.
>
> Signed-off-by: Andrew Cooper
Acked-by: Ian Campbell
> CC: Ian Jackson
> CC: Wei Liu
> ---
> tools/libxl/libxl_internal.h | 16
> 1 file changed, 16 insertions(+)
>
> diff --
On Fri, Feb 20, 2015 at 3:44 PM, Ian Campbell wrote:
> On Thu, 2015-02-19 at 18:01 +, Julien Grall wrote:
>> Based on the discussion, what about waiting until someone complain about
>> GICv3 support on Xen 4.5?
>
> That sounds like a reasonable compromise.
If Xen 4.5 claims GICv3 support, the
On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
> 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.
Please can you clarify this commit message. Questions I'm
On 19/02/15 23:09, Linus Torvalds wrote:
> On Thu, Feb 19, 2015 at 5:06 AM, David Vrabel wrote:
>>
>> The NUMA_BALANCING series beginning with 5d833062139d (mm: numa: do not
>> dereference pmd outside of the lock during NUMA hinting fault) and
>> specifically 8a0516ed8b90 (mm: convert p[te|md]_num
On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
> 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.
http://lists.xen.org/archives/html/xen-devel/2014-09/msg01806.html:
On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
> From: Ross Lagerwall
>
> Add a parameter, maxread, to limit the amount of data read from the
> source fd of a datacopier.
http://lists.xen.org/archives/html/xen-devel/2014-09/msg01802.html and
followups.
___
On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
> 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.
http://lists.xen.org/archives/html/xen-
>>> On 19.02.15 at 18:11, wrote:
> --- a/xen/include/xen/perfc_defn.h
> +++ b/xen/include/xen/perfc_defn.h
> @@ -53,4 +53,8 @@ PERFCOUNTER(vcpu_hot, "csched: vcpu_hot")
>
> PERFCOUNTER(need_flush_tlb_flush, "PG_need_flush tlb flushes")
>
> +/* Viridian counters */
> +PERFCOUNT
2015-02-18 16:34 GMT+00:00 Andrew Cooper :
> 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/lib
On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
> 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
On Fri, 2015-02-20 at 15:56 +0530, Vijay Kilari wrote:
> On Fri, Feb 20, 2015 at 3:44 PM, Ian Campbell wrote:
> > On Thu, 2015-02-19 at 18:01 +, Julien Grall wrote:
> >> Based on the discussion, what about waiting until someone complain about
> >> GICv3 support on Xen 4.5?
> >
> > That sounds
On 20/02/15 01:49, Linus Torvalds wrote:
> On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov
> wrote:
>> I'm feeling I miss very basic background on how Xen works, but why does it
>> set _PAGE_GLOBAL on userspace entries? It sounds strange to me.
> It is definitely strange. I'm guessing that it'
>>> On 20.02.15 at 05:47, wrote:
> I'm trying to use the memevent channel to extract the permission for a
> particular text section. I expect to see rx as the permission, instead
> I am seeing rwx. I have not spent a whole lot of time looking at
> memaccess[] and p2m-ept.c, but I am puzzled. The O
On 20/02/15 10:42, Frediano Ziglio wrote:
> 2015-02-18 16:34 GMT+00:00 Andrew Cooper :
>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>> index 934465a..a2b6fb7 100644
>> --- a/tools/libxl/libxl_internal.h
>> +++ b/tools/libxl/libxl_internal.h
>> @@ -108,6 +108,22 @@
>>
On 20/02/15 10:27, Ian Campbell wrote:
> On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
>> 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.
> Please can
On Fri, 2015-02-20 at 11:10 +, Andrew Cooper wrote:
> On 20/02/15 10:27, Ian Campbell wrote:
> > On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
> >> From: Wen Congyang
> >>
> >> datacopier is to read some data and write it out. If we
> >> have some data to send it over network, we can
On 20/02/15 10:44, Ian Campbell wrote:
> On Fri, 2015-02-20 at 15:56 +0530, Vijay Kilari wrote:
>> On Fri, Feb 20, 2015 at 3:44 PM, Ian Campbell
>> wrote:
>>> On Thu, 2015-02-19 at 18:01 +, Julien Grall wrote:
Based on the discussion, what about waiting until someone complain about
In order to keep the tree bisectable all the changes are done in one
single commit.
Things done in this commit:
1. Import necessary .mk files from Xen.
2. Move all XEN_ related variables to MINIOS_ namespace.
3. Import Xen public header files.
4. Import BSD's list.h and helper script.
Mini-OS's
Don't look for mini-os source file during configure. Mini-os source code
will be fetched during build.
Instead look for xenstore-minios.cfg.
Please rerun autogen.sh after applying this patch.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
Changes in v2:
1. Look for xenstore-minio
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Acked-by: Ian Campbell
[ output trimmed ]
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Provide mini-os url and revision in Config.mk
Introduce Makefile.mini-os which contains mini-os specific targets.
Target mini-os-dir clones mini-os tree from upstream.
Make stubdom targets depend on mini-os-dir target. Make
subtree-force-update{,-all} depend on mini-os-dir-force-update.
Also mak
Otherwise mkdir extras/mini-os fails because extras doesn't exist.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Acked-by: Ian Campbell
---
scripts/git-checkout.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh
i
This is v2 of my mini-os splitting off patch series.
I use following runes to split off mini-os:
git filter-branch --tag-name-filter cat \
--subdirectory-filter extras/mini-os/ -- --all
# There is already a tag name 4.3.0-rc2 which points to the same commit.
git tag -d xen-4.3.0-rc2
Factor out per-subsystem build/clean/distclean-% targets, so that we can
build subsystems independently in top level directory.
The motive behind this is after splitting out mini-os from Xen tree,
stubdom is in effect a downstream of mini-os. I would like to have the
ability to build it independe
Cross compiling libxc requires some symlinks to exist.
Note that make -C tools/include requires running tools/configure. But at
least now the error message is much better than just a "file not found"
error.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jakcson
Acked-by: Ian Campbell
Acked-b
Hi Ian,
On 20/02/15 10:14, Ian Campbell wrote:
> On Thu, 2015-02-19 at 18:01 +, Julien Grall wrote:
>> Based on the discussion, what about waiting until someone complain about
>> GICv3 support on Xen 4.5?
>
> That sounds like a reasonable compromise.
>
> My potential backports list now conta
flight 34707 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34707/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 34622
test-amd64-amd64-xl-qe
At 15:12 + on 19 Feb (1424355171), Jan Beulich wrote:
> >>> On 19.02.15 at 15:47, wrote:
> > Tim suggested posting this patch to see what general opinion was to this
> > style of backport fix. I attempted to backport the EPT misconfig to Xen
> > 4.4 but I ended up with quite a large number of
This patch series adds PCI support for XEN ARM.
- pci config read writes maps to xen-arm pci.c
- platform support includes parsing pci device tree node and callbacks
for reading writing from configuration space
- placeholder code is added which is necessary for compilation
Next RFC Patch set will
The platform APIs are enhanced to provide support for parsing pci device
tree nodes and storing the config-space address which is later used for
pci_read/pci_write config calls.
---
xen/arch/arm/platform.c| 27 +++
xen/include/asm-arm/platform.h | 18 ++
Support added for the thunderX platfrom for reading writing config space
---
xen/arch/arm/platforms/thunderx.c | 124 ++
1 file changed, 124 insertions(+)
diff --git a/xen/arch/arm/platforms/thunderx.c
b/xen/arch/arm/platforms/thunderx.c
index 96560e1..1b6f0c
On Fri, Feb 20, 2015 at 4:19 PM, Jan Beulich wrote:
On 20.02.15 at 05:47, wrote:
>> I'm trying to use the memevent channel to extract the permission for a
>> particular text section. I expect to see rx as the permission, instead
>> I am seeing rwx. I have not spent a whole lot of time lookin
This patch adds support for pci in xen arm. Following features are
added
a) pci device tree node is parsed and platform callback is invoked
For thunderX the callback stores the reg property, which is later
used in generating address based on the s:b:d.f
b) ABI followed is segment no is mapped to
>>> On 20.02.15 at 12:44, wrote:
> On Fri, Feb 20, 2015 at 4:19 PM, Jan Beulich wrote:
> On 20.02.15 at 05:47, wrote:
>>> I'm trying to use the memevent channel to extract the permission for a
>>> particular text section. I expect to see rx as the permission, instead
>>> I am seeing rwx. I h
Hello manish,
On 20/02/15 11:30, Manish Jaggi wrote:
> This patch series adds PCI support for XEN ARM.
> - pci config read writes maps to xen-arm pci.c
> - platform support includes parsing pci device tree node and callbacks
> for reading writing from configuration space
> - placeholder code is ad
>>> On 20.02.15 at 12:47, wrote:
> @@ -287,6 +289,7 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg,
> u8 bus, u8 devfn)
> if ( pci_find_cap_offset(pseg->nr, bus, PCI_SLOT(devfn),
> PCI_FUNC(devfn),
>PCI_CAP_ID_MSIX) )
> {
> +#ifndef CONFIG_A
On 20/02/15 11:29, Kirill A. Shutemov wrote:
> On Fri, Feb 20, 2015 at 10:47:52AM +, Andrew Cooper wrote:
>> On 20/02/15 01:49, Linus Torvalds wrote:
>>> On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov
>>> wrote:
I'm feeling I miss very basic background on how Xen works, but why does
On 20/02/15 5:23 pm, Julien Grall wrote:
Hello manish,
On 20/02/15 11:30, Manish Jaggi wrote:
This patch series adds PCI support for XEN ARM.
- pci config read writes maps to xen-arm pci.c
- platform support includes parsing pci device tree node and callbacks
for reading writing from configura
On 20/02/15 11:56, Manish Jaggi wrote:
>
> On 20/02/15 5:23 pm, Julien Grall wrote:
>> Hello manish,
>>
>> On 20/02/15 11:30, Manish Jaggi wrote:
>>> This patch series adds PCI support for XEN ARM.
>>> - pci config read writes maps to xen-arm pci.c
>>> - platform support includes parsing pci devic
On 20/02/15 5:28 pm, Julien Grall wrote:
On 20/02/15 11:56, Manish Jaggi wrote:
On 20/02/15 5:23 pm, Julien Grall wrote:
Hello manish,
On 20/02/15 11:30, Manish Jaggi wrote:
This patch series adds PCI support for XEN ARM.
- pci config read writes maps to xen-arm pci.c
- platform support incl
Hello Manish,
On 20/02/15 11:34, Manish Jaggi wrote:
> The platform APIs are enhanced to provide support for parsing pci device
> tree nodes and storing the config-space address which is later used for
> pci_read/pci_write config calls.
Can you explain why you choose to add per-platform callbacks
On 20/02/15 5:23 pm, Jan Beulich wrote:
On 20.02.15 at 12:47, wrote:
@@ -287,6 +289,7 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg,
u8 bus, u8 devfn)
if ( pci_find_cap_offset(pseg->nr, bus, PCI_SLOT(devfn),
PCI_FUNC(devfn),
PCI_CAP_ID_MSIX) )
On 20/02/15 5:33 pm, Julien Grall wrote:
Hello Manish,
On 20/02/15 11:34, Manish Jaggi wrote:
The platform APIs are enhanced to provide support for parsing pci device
tree nodes and storing the config-space address which is later used for
pci_read/pci_write config calls.
Can you explain why y
On 20/02/15 12:05, Manish Jaggi wrote:
> On 20/02/15 5:23 pm, Jan Beulich wrote:
>> All of these #ifdef-s call for better abstraction. And in no case is it
>> acceptable to replace blank lines with #ifdef-s like you do.
> Good observation. I will take care for the blank lines.
> A lot of code exist
On Fri, 2015-02-06 at 12:37 +, Stefano Stabellini wrote:
> On Fri, 30 Jan 2015, Julien Grall wrote:
> > Some drivers may want to configure differently the device depending on
> > the compatible string. For this purpose, add a new field in the
> > dt_device_match to store the data.
> >
> > Also
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> The header asm/device.h has been included in the vgic code during
> splitting to support multiple version. But no code within those files
> requires it.
>
> Signed-off-by: Julien Grall
> Acked-by: Stefano Stabellini
Acked-by: Ian Campbell
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> I'm not sure why a ':' has been added in the name... But none of the
> other usages doesn't have it.
>
> Signed-off-by: Julien Grall
> Acked-by: Stefano Stabellini
Acked-by: Ian Campbell
___
On Fri, 2015-02-06 at 12:38 +, Stefano Stabellini wrote:
> On Fri, 30 Jan 2015, Julien Grall wrote:
> > This enum was used for matching a specific class of device and not to get
> > the
> > type of device.
> >
> > Hence the name device_type will be used for another purpose later.
> >
> > Als
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> The current SMMU driver has completly diverged. That makes me hard to
> maintain.
Will this temporarily regress anything in a noticeable way? I think
it'll just potentially make some hypothetical platform switch back to
1:1 dom0 mode, which
On 20/02/15 12:10, Manish Jaggi wrote:
>
> On 20/02/15 5:33 pm, Julien Grall wrote:
>> Hello Manish,
>>
>> On 20/02/15 11:34, Manish Jaggi wrote:
>>> The platform APIs are enhanced to provide support for parsing pci device
>>> tree nodes and storing the config-space address which is later used for
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> @@ -2,8 +2,34 @@
> #define __ASM_ARM_DEVICE_H
>
> #include
> +
> +enum device_type
> +{
> +DEV_DT,
I suppose no #ifdef here because an empty enum is a bit silly?
>
> +/* TODO: Correctly implement dev_is_pci when PCI will be suppo
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> On ARM, the way to assign device tree node is exactly the same as PCI.
> Futhermore, all devices can be represented by a 'device_t'.
> Therefore there is no need to add separate ops.
>
> The x86 iommu drivers has not been modified to replace
by providing the definition of the {w,r}rmsr_tsc_msr counters,
used within Viridian implementation.
Signed-off-by: Dario Faggioli
Cc: Paul Durrant
CC: Jan Beulich
Cc: Andrew Cooper
---
Changes from v1:
* put the macros in xen/include/asm-x86/perfc_defn.h,
where they belong, as requested du
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
Subject: "devices"
> Xen is currently using list a compatible string to know if the driver
"using a list of compatible strings"
rather than "if the driver can use device node" I'd say something like
"to match drivers against device nodes".
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3.
>
> It's a verbatim of the Linux SMMU drivers code. No Xen code has yet been added
> and the file is not built.
>
> Compare to the previous drivers it gains support of PCI. Though it
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> From: Andreas Herrmann
>
> If DT information lists one stream ID twice for the master devices of
> an SMMU this can cause a multi match when stream ID matching is used.
> For stream ID indexing this might trigger an overwrite of an S2CR tha
On 20/02/15 5:50 pm, Julien Grall wrote:
On 20/02/15 12:10, Manish Jaggi wrote:
On 20/02/15 5:33 pm, Julien Grall wrote:
Hello Manish,
On 20/02/15 11:34, Manish Jaggi wrote:
The platform APIs are enhanced to provide support for parsing pci device
tree nodes and storing the config-space addre
Hi Ian,
On 20/02/15 12:18, Ian Campbell wrote:
> On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
>> The current SMMU driver has completly diverged. That makes me hard to
>> maintain.
>
> Will this temporarily regress anything in a noticeable way? I think
> it'll just potentially make some
On 20/02/15 6:04 pm, Manish Jaggi wrote:
On 20/02/15 5:50 pm, Julien Grall wrote:
On 20/02/15 12:10, Manish Jaggi wrote:
On 20/02/15 5:33 pm, Julien Grall wrote:
Hello Manish,
On 20/02/15 11:34, Manish Jaggi wrote:
The platform APIs are enhanced to provide support for parsing pci
device
tr
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> From: Andreas Herrmann
>
> Try to determine mask/id values that match several stream IDs of a
> master device when doing Stream ID matching. Thus the number of used
> SMR groups that are required to map all stream IDs of a master device
> t
On Fri, Feb 20, 2015 at 10:47:52AM +, Andrew Cooper wrote:
> On 20/02/15 01:49, Linus Torvalds wrote:
> > On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov
> > wrote:
> >> I'm feeling I miss very basic background on how Xen works, but why does it
> >> set _PAGE_GLOBAL on userspace entries? I
On Fri, 2015-02-06 at 13:20 +, Stefano Stabellini wrote:
> > +#define iommu_group_get_iommudata(group) (group)->cfg
>
> I would move all the Xen stuff at the beginning of the file or maybe to
> a separate file. You could #include the linux smmu driver into it.
> Maybe we cannot have runtime pa
On Mon, 2015-02-09 at 23:40 +0800, Julien Grall wrote:
> Hi Stefano,
>
> On 06/02/2015 21:20, Stefano Stabellini wrote:
> > On Fri, 30 Jan 2015, Julien Grall wrote:
> >> -static int force_stage;
> >> -module_param_named(force_stage, force_stage, int, S_IRUGO | S_IWUSR);
> >> -MODULE_PARM_DESC(forc
On Tue, Feb 17, 2015 at 03:29:35PM +, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
>
Acked-by: Wei Liu
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -347,6 +347,7 @@
> F: xen/arch/x86/
> F: xen/include/asm-x86/
> F: tools/firmware/hvmloader/
> +F: tools/tests/x86_emulator/
>
On 20/02/15 12:31, Ian Campbell wrote:
> On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
>> Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3.
>>
>> It's a verbatim of the Linux SMMU drivers code. No Xen code has yet been
>> added
>> and the file is not built.
>>
>> Compare to the pr
On 20/02/15 12:35, Ian Campbell wrote:
> On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
>> From: Andreas Herrmann
>>
>> If DT information lists one stream ID twice for the master devices of
>> an SMMU this can cause a multi match when stream ID matching is used.
>> For stream ID indexing t
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> @@ -2896,6 +2911,16 @@ static __init int arm_smmu_dt_init(struct
> dt_device_node *dev,
> if ( !rc )
> iommu_set_ops(&arm_smmu_iommu_ops);
>
> + /*
> + * The last added SMMU is the first element of arm_smmu_dev
On Fri, 2015-02-20 at 12:20 +, Julien Grall wrote:
> Overall, I would prefer to have a separate file and structure for
> handling PCI host. Also, I think we could re-use the Linux code for this
> purpose.
(caveat; I've not looked at the code yet)
I had expected that PCI host controllers would
On 20/02/15 13:15, Ian Campbell wrote:
> On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
>> From: Andreas Herrmann
>>
>> Try to determine mask/id values that match several stream IDs of a
>> master device when doing Stream ID matching. Thus the number of used
>> SMR groups that are required
(Jan, curious if you have any thoughts on this, hopefully I've left
sufficient context for you to get what we are on about, the gist is we
need some way for dom0 and Xen to agree on how a PCI segment ID maps to
an actual PCI root controller, I think on x86 you either Just Know from
PC legacy or ACP
On Fri, 2015-02-20 at 13:33 +, Julien Grall wrote:
> On 20/02/15 12:31, Ian Campbell wrote:
> > On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> >> Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3.
> >>
> >> It's a verbatim of the Linux SMMU drivers code. No Xen code has yet bee
On Fri, 2015-02-20 at 13:34 +, Julien Grall wrote:
> On 20/02/15 12:35, Ian Campbell wrote:
> > On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> >> From: Andreas Herrmann
> >>
> >> If DT information lists one stream ID twice for the master devices of
> >> an SMMU this can cause a multi
On Fri, 2015-02-20 at 12:53 +, Julien Grall wrote:
> Hi Ian,
>
> On 20/02/15 12:18, Ian Campbell wrote:
> > On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> >> The current SMMU driver has completly diverged. That makes me hard to
> >> maintain.
> >
> > Will this temporarily regress an
Hi Ian,
On 20/02/15 13:23, Ian Campbell wrote:
> On Fri, 2015-02-06 at 13:20 +, Stefano Stabellini wrote:
>>> +#define iommu_group_get_iommudata(group) (group)->cfg
>>
>> I would move all the Xen stuff at the beginning of the file or maybe to
>> a separate file. You could #include the linux sm
On 19/02/15 16:50, Boris Ostrovsky wrote:
> On 02/19/2015 10:23 AM, David Vrabel wrote:
>> Hypercalls submitted by user space tools via the privcmd driver can
>> take a long time (potentially many 10s of seconds) if the hypercall
>> has many sub-operations.
>>
>> A fully preemptible kernel may desc
On 17/02/15 07:02, Juergen Gross wrote:
> A request in the ring buffer mustn't be read after it has been marked
> as consumed. Otherwise it might already have been reused by the
> frontend without violating the ring protocol.
>
> To avoid inconsistencies in the backend only work on a private copy
On 20/02/15 13:47, Ian Campbell wrote:
> On Fri, 2015-02-20 at 12:53 +, Julien Grall wrote:
> The main thing I'm worried about is if the bisector is searching a range
> which includes this change looking for some unrelated change and this
> commit causes some sort of spurious issue or perturbat
On Fri, 2015-02-20 at 13:42 +, Julien Grall wrote:
> >> - Use num_s2crs rather than num_streamids in the arm_smmu_free_smrs.
> >> This former is the field used to configure SRMS
> >>
> >> Cc: Andreas Herrmann
> >> Signed-off-by: Andreas Herrmann
> >> Signed-off-by: Julien Grall
> >>
On 18/02/15 10:12, 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 other
>>> files in arch/x8
On 20/02/15 10:43, Ian Campbell wrote:
> On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
>> 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
>>> On 16.02.15 at 23:26, wrote:
> --- a/xen/arch/x86/hvm/svm/vpmu.c
> +++ b/xen/arch/x86/hvm/svm/vpmu.c
> @@ -253,6 +253,26 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
> return 1;
> }
>
> +static void amd_vpmu_unload(struct vpmu_struct *vpmu)
> +{
> +struct vcpu *v;
> +
> +
On 20/02/15 13:29, Ian Campbell wrote:
> On Mon, 2015-02-09 at 23:40 +0800, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 06/02/2015 21:20, Stefano Stabellini wrote:
>>> On Fri, 30 Jan 2015, Julien Grall wrote:
-static int force_stage;
-module_param_named(force_stage, force_stage, int, S_IR
On Fri, 2015-02-20 at 13:55 +, Andrew Cooper wrote:
> >
> > It's a bit of a shame that callers which don't care about specific
> > pollhup handling have to provide two practically identical handlers.
>
> Up until this patch, all users either provided no POLLHUP handler, or
> provided the same
On 20/02/15 14:06, Ian Campbell wrote:
> On Fri, 2015-02-20 at 13:53 +, Julien Grall wrote:
>> On 20/02/15 13:47, Ian Campbell wrote:
>>> On Fri, 2015-02-20 at 12:53 +, Julien Grall wrote:
>>> The main thing I'm worried about is if the bisector is searching a range
>>> which includes this c
On Fri, 2015-02-20 at 13:53 +, Julien Grall wrote:
> On 20/02/15 13:47, Ian Campbell wrote:
> > On Fri, 2015-02-20 at 12:53 +, Julien Grall wrote:
> > The main thing I'm worried about is if the bisector is searching a range
> > which includes this change looking for some unrelated change an
On 20/02/15 13:34, Ian Campbell wrote:
> On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
>> @@ -2896,6 +2911,16 @@ static __init int arm_smmu_dt_init(struct
>> dt_device_node *dev,
>> if ( !rc )
>> iommu_set_ops(&arm_smmu_iommu_ops);
>>
>> +/*
>> + * The last add
On Thu, Feb 12, 2015 at 07:19:13PM +0800, Ard Biesheuvel wrote:
> While Xen on Intel uses a virtual PCI device to communicate the
> base address of the grant table, the ARM implementation uses a DT
> node, which is fundamentally incompatible with the way XenBusDxe is
> implemented, i.e., as a UEFI
On Tue, 2015-02-17 at 15:29 +, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 20.02.15 at 14:45, wrote:
> (Jan, curious if you have any thoughts on this, hopefully I've left
> sufficient context for you to get what we are on about, the gist is we
> need some way for dom0 and Xen to agree on how a PCI segment ID maps to
> an actual PCI root controller, I think on x86
>>> On 16.02.15 at 23:26, wrote:
> Move some VPMU initilization operations into __initcalls to avoid performing
> same tests and calculations for each vcpu.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-dev
On Fri, 2015-02-20 at 14:07 +, Julien Grall wrote:
> On 20/02/15 13:34, Ian Campbell wrote:
> > On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> >> @@ -2896,6 +2911,16 @@ static __init int arm_smmu_dt_init(struct
> >> dt_device_node *dev,
> >>if ( !rc )
> >>iommu_set_op
On 20/02/15 14:13, Ian Campbell wrote:
> On Fri, 2015-02-20 at 14:07 +, Julien Grall wrote:
>> On 20/02/15 13:34, Ian Campbell wrote:
>>> On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
@@ -2896,6 +2911,16 @@ static __init int arm_smmu_dt_init(struct
dt_device_node *dev,
1 - 100 of 188 matches
Mail list logo
