On 2015/2/18 21:22, Ian Campbell wrote:
On Wed, 2015-02-11 at 10:45 +0800, Chen, Tiejun wrote:
On 2015/2/9 19:05, Ian Campbell wrote:
On Mon, 2015-02-09 at 14:28 +0800, Chen, Tiejun wrote:
What about this?
I've not read the code in detail,since I'm travelling but from a quick
glance it look
Using the pvops kernel a NULL pointer dereference was detected on a
large machine (144 processors) when booting as dom0 in
evtchn_fifo_unmask() during assignment of a pirq.
The event channel in question was the first to need a new entry in
event_array[] in events_fifo.c. Unfortunately xen_irq_info
On 02/26/2015 02:53 AM, Luis R. Rodriguez wrote:
OK here's the state of affairs after some further discussion on some v3 patch
RFC changes and issues I've found after trying to build front end drivers
without CONFIG_XEN.
Option Selects Depends
---
Hi Guys,
I just follow the guide in the link[1], and looks
I can boot Dom0 successfully on mustang, and the
xen 4.5 tools can be built OK on Dom0 side too.
But when I try to create domU with the following
commands:
# losetup -f arm64-fs1.img
# losetup -a
/dev/loop0: [0802]:1318964 (/
OK here's the state of affairs after some further discussion on some v3 patch
RFC changes and issues I've found after trying to build front end drivers
without CONFIG_XEN.
Option Selects Depends
--
From: Arnd Bergmann
Use pci_scan_root_bus() instead of deprecated function
pci_scan_bus_parented().
Signed-off-by: Arnd Bergmann
Signed-off-by: Yijing Wang
CC: Konrad Rzeszutek Wilk
CC: xen-de...@lists.xenproject.org
---
drivers/pci/xen-pcifront.c | 10 +++---
1 files changed, 7 insert
Now we could pass PCI domain combined with bus number
in u32 argu. Because in arm/arm64, PCI domain number
is assigned by pci_bus_assign_domain_nr(). So we leave
pci_scan_root_bus() and pci_create_root_bus() in arm/arm64
unchanged. A new function pci_host_assign_domain_nr()
will be introduced for a
flight 35242 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35242/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 33391
Tests which did not succe
On Wed, Feb 25, 2015 at 02:33:40PM +, Stefano Stabellini wrote:
> On Wed, 25 Feb 2015, David Vrabel wrote:
> > On 25/02/15 14:17, Stefano Stabellini wrote:
> > > On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
> > >> From: "Luis R. Rodriguez"
> > >>
> > >> This unwraps XEN_BACKEND from depending
On Wednesday, February 25, 2015 03:07:25 PM Stefano Stabellini wrote:
> freemem_slack accounts for the amount of memory to be left free in the
> system because empirical experiments seem to demonstrate that is needed
> for "stability reasons".
>
> As we don't have any actual data on these stabilit
On Wed, Feb 25, 2015 at 03:45:56PM +, Stefano Stabellini wrote:
> On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > This will later more easily let us unfold PARAVIRT and PARAVIRT_CLOCK
> > from under CONFIG_XEN. All the XEN_PV* stuff is under the x86 univers
On Wed, Feb 25, 2015 at 03:44:53PM +, Stefano Stabellini wrote:
> On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > This lets us expose XEN_PVH and set what is required for it.
> > This only exists on the x86 universe. This is as per the agreed
> > upon Xen K
On Wed, Feb 25, 2015 at 02:27:08PM +, Stefano Stabellini wrote:
> On Wed, 25 Feb 2015, Stefano Stabellini wrote:
> > On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
> > > On Tue, Feb 24, 2015 at 7:21 AM, Stefano Stabellini
> > > wrote:
> > > > On Mon, 23 Feb 2015, Luis R. Rodriguez wrote:
> > >
flight 35323 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35323/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 3 host-install(3) broken in 35204 REGR. vs. 341
flight 35241 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35241/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 3 host-install(3) broken REGR. vs. 34877
b
A set of patches for better px2<->node mapping and consistent use of
nodeID datatype.
Boris Ostrovsky (3):
x86/numa: Allow arbitrary value of PXM in PXM<->node mapping
x86/numa: Adjust datatypes for node and pxm
mm: MEMF_node should handle changes in nodeid_t size
xen/arch/x86/irq.c
ACPI defines proximity domain identifier as a 32-bit integer. While
in most cases the values will be zero-based this is not guaranteed,
making current pxm2node[256] mapping structure not appropriate.
We will instead use MAX_NUMNODES-sized array of struct pxm2node to
store PXM-to-node mapping. To a
Use u8-sized node IDs and unsigned PXMs consistently throughout
code (and introduce nodeid_t type).
Signed-off-by: Boris Ostrovsky
---
Changes n v3:
* Moved node declaration in cpu_add() into its scope.
xen/arch/x86/irq.c |4 +-
xen/arch/x86/numa.c | 15 +
Instead of using a hardcoded constant to extract nodeID from
memflags use a macro whose value is based on nodeid_t size.
Also provide a macro for extracting nodeID from memflags so that
users don't need to remember to decrement the value.
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Fixe
>
> I see no way then in which init_hvm_pv_info() would be called for XEN_PV
> and XEN_PVH. In fact should we not be able to just BUG_ON(xen_pv_domain())
> above?
/me nods.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-de
On 25 February 2015 at 21:56, Kinney, Michael D
wrote:
> Ard Biesheuvel,
>
> Thank you for providing the implementation of this new function for all
> supported CPU architectures. The one for IPF looks correct and passes builds.
Good. Thanks for confirming that.
> However, I am seeing some bui
On Wed, Feb 25, 2015 at 12:01:31PM +, Stefano Stabellini wrote:
> On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
> > On Tue, Feb 24, 2015 at 7:21 AM, Stefano Stabellini
> > wrote:
> > > On Mon, 23 Feb 2015, Luis R. Rodriguez wrote:
> > >> On Thu, Feb 19, 2015 at 3:43 PM, Luis R. Rodriguez
> >
Ard Biesheuvel,
Thank you for providing the implementation of this new function for all
supported CPU architectures. The one for IPF looks correct and passes builds.
However, I am seeing some build breaks and some issues with the IA32 and X64
versions. The following changes are required to y
On Wed, Feb 25, 2015 at 01:25:59PM -0800, Luis R. Rodriguez wrote:
> On Wed, Feb 25, 2015 at 1:19 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Wed, Feb 25, 2015 at 01:11:04PM -0800, David Rientjes wrote:
> >> On Wed, 25 Feb 2015, Luis R. Rodriguez wrote:
> >>
> >> > I am reworking Xen's kconfig stuff
On Wed, Feb 25, 2015 at 1:19 PM, Konrad Rzeszutek Wilk
wrote:
> On Wed, Feb 25, 2015 at 01:11:04PM -0800, David Rientjes wrote:
>> On Wed, 25 Feb 2015, Luis R. Rodriguez wrote:
>>
>> > I am reworking Xen's kconfig stuff right now, so perhaps what is best
>> > is for this series to be folded under
On Wed, Feb 25, 2015 at 01:11:04PM -0800, David Rientjes wrote:
> On Wed, 25 Feb 2015, Luis R. Rodriguez wrote:
>
> > I am reworking Xen's kconfig stuff right now, so perhaps what is best
> > is for this series to be folded under those changes and I'd submit
> > them as the last series in the chan
On Wed, Feb 25, 2015 at 12:49 PM, David Rientjes wrote:
> Woohoo, so does this mean that Luis's series will finally be merged into a
> tree somewhere? It's been a lengthy wait to try to get this merged.
David Rientjes (as I'm also Cc'ing David Vrabel),
I am reworking Xen's kconfig stuff right
On 02/25/15 10:07, Stefano Stabellini wrote:
> LIBXL_MAXMEM_CONSTANT is used to increase the maxmem setting for a
> domain by a constant amount. As it is not clear the reason why we should
> be doing this, remove the constant.
>
> Signed-off-by: Stefano Stabellini
> CC: mlati...@suse.com
> CC: ia
On 02/24/15 10:34, Jan Beulich wrote:
On 17.02.15 at 00:05, wrote:
>> @@ -501,22 +542,50 @@ static void hvm_free_ioreq_gmfn(struct domain *d,
>> unsigned long gmfn)
>> clear_bit(i, &d->arch.hvm_domain.ioreq_gmfn.mask);
>> }
>>
>> -static void hvm_unmap_ioreq_page(struct hvm_ioreq_ser
Wei Liu, le Wed 25 Feb 2015 11:21:27 +, a écrit :
> All objects are placed inside stubdom's directories, so there is no need
> to enter mini-os and clean.
>
> Signed-off-by: Wei Liu
> Cc: Ian Campbell
> Cc: Ian Jackson
> Cc: Samuel Thibault
> Cc: Stefano Stabellini
Acked-by: Samuel Thiba
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 'struct pci_dev'
by "device_t" because the latter is an alias of
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 will
need a bit of plumbing for Xen.
Signed-off-by: Julien Grall
Currently, Xen is supporting PCI and Platform device (based on Device Tree).
While Xen only supports Platform device on ARM, Xen will gain support of
PCI soon.
Some drivers, such as IOMMU drivers, may handle PCI and platform device in
the same way. Only few lines of code differs.
Rather than req
Hello,
The SMMU driver has diverged from Linux. Having our own driver doesn't make
any benefits and make difficult to backport fixes and/or porting features
such as PCI.
With this series, the code of the SMMU drivers (copied from Linux) is mostly
not modified. If it's the case a comment /* Xen: .
The main goal is to modify as little the Linux code to be able to port
easily new feature added in Linux repo for the driver.
To achieve that we:
- Add helpers to Linux function not implemented on Xen
- Add callbacks used by Xen to do our own stuff and call Linux ones
- Only modify whe
The current SMMU driver has completly diverged. That makes me hard to
maintain.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
Acked-by: Ian Campbell
---
Currently none of the platform used on OSStest has SMMU nodes
described in the device tree. Therefore, the bisector won't
Basic changes to support SMMUs which protect the network cards. The one
for the SATA is more complicate to support because it requires to
support stream ID matching.
Signed-off-by: Julien Grall
---
xen/drivers/passthrough/arm/smmu.c | 32 +++-
1 file changed, 27 inser
Xen is currently using a list of compatible strings to match drivers again
device nodes. This leads to having double definitions in the GIC
code.
Furthermore Linux drivers are using dt_device_match (actually called
of_device_id in Linux) to list device supported by the drivers.
Remove the exisiti
When SMMU doesn't support coherent table walk, Xen may need to clean
updated PT (see commit 4c5f4cb "xen/arm: p2m: Clean cache PT when the
IOMMU doesn't support coherent walk").
If one SMMU of the platform doesn't support coherent table walk, the
feature is disabled for the whole platform. This is
On Wed, Feb 25, 2015 at 04:40:40PM +, Ian Campbell wrote:
> On Wed, 2015-02-25 at 16:34 +, Will Deacon wrote:
> > On Wed, Feb 25, 2015 at 04:22:33PM +, Julien Grall wrote:
> > > Hello,
> > >
> > > Ping? Any comments from ARM's maintainers on theses patches (at least #2)?
> >
> > I cou
Ian and Ian,
Currently OSSTest pushes OVMF changesets to osstest/ovmf.git, while
xen.git references ovmf.git. This requires us to do manual push from
osstest/ovmf.git to ovmf.git.
I would like to just reference master in Xen's Config.mk. I suppose we
should make OSSTest to push to both ovmf.git
On 25/02/15 14:45, Jan Beulich wrote:
> ... when calculating how many pages to allocate fopr Dom0. This is
"fopr" => "for" ?
> basically equivalent to the already present IOMMU related adjustment.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_bu
On Wed, 2015-02-25 at 16:34 +, Stefano Stabellini wrote:
> I am concerned about the increased size of the Xen binary as a result of
> the introduction of this driver.
I'm also somewhat concerned about the ongoing maintenance of a
proliferation of (subtly or otherwise) different interrupt contr
On Wed, 25 Feb 2015, Frediano Ziglio wrote:
> 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-hip04.c | 10 +++---
> 1 file changed,
> On Fri, 2015-02-20 at 09:56 +, Frediano Ziglio wrote:
> > This set of patches add Xen support for hip04-d01 platform (see
> > https://wiki.linaro.org/Boards/D01 for details).
>
> When (or where) would the general public be able to purchase one of
> these systems?
>
> Ian.
These exact board
On Wed, 25 Feb 2015, Frediano Ziglio wrote:
> 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 max
On Wed, 25 Feb 2015, Frediano Ziglio wrote:
> 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-hip04.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/xen/arch/a
On Fri, 2015-02-20 at 09:56 +, Frediano Ziglio wrote:
> This set of patches add Xen support for hip04-d01 platform (see
> https://wiki.linaro.org/Boards/D01 for details).
When (or where) would the general public be able to purchase one of
these systems?
Ian.
On Wed, 2015-02-25 at 16:34 +, Will Deacon wrote:
> On Wed, Feb 25, 2015 at 04:22:33PM +, Julien Grall wrote:
> > Hello,
> >
> > Ping? Any comments from ARM's maintainers on theses patches (at least #2)?
>
> I couldn't care less :)
>
> The arm64 part is boring in the good sense of the wo
On Wed, 25 Feb 2015, Frediano Ziglio wrote:
> HiSilison Hip04 platform use a slightly different version
>
> Signed-off-by: Frediano Ziglio
I think that this is preferable to the previous approach of modifying
the existing gic-v2 driver, after all the hip04 interrupt controller is
not a gicv2.
On 25/02/15 14:47, Jan Beulich wrote:
> Remove a redundant statement from parse_dom0_mem() and refuse bogus
> ranges (with a separator other than a dash) passed to
> parse_dom0_max_vcpus(). Fix coding style issues in the latter function
> at the same time.
>
> Signed-off-by: Jan Beulich
Reviewed-
On 25/02/15 16:34, Will Deacon wrote:
> On Wed, Feb 25, 2015 at 04:22:33PM +, Julien Grall wrote:
>> Hello,
>>
>> Ping? Any comments from ARM's maintainers on theses patches (at least #2)?
>
> I couldn't care less :)
> The arm64 part is boring in the good sense of the word.
I will still need
On Wed, Feb 25, 2015 at 04:22:33PM +, Julien Grall wrote:
> Hello,
>
> Ping? Any comments from ARM's maintainers on theses patches (at least #2)?
I couldn't care less :)
The arm64 part is boring in the good sense of the word.
Will
___
Xen-devel m
On 02/25/2015 10:12 AM, kevin.ma...@gdata.de wrote:
-Ursprüngliche Nachricht-
Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
Gesendet: Dienstag, 24. Februar 2015 18:13
An: Mayer, Kevin; xen-devel@lists.xen.org
Betreff: Re: [Xen-devel] Branch Trace Storage for guests and VPMU
ini
Hello,
Ping? Any comments from ARM's maintainers on theses patches (at least #2)?
Regards,
On 18/02/15 13:51, Julien Grall wrote:
> Hello,
>
> This small patch series moves the detection of running on Xen earlier. This is
> required in order to support earlyprintk via Xen and selecting preferre
On 02/25/2015 03:24 PM, David Vrabel wrote:
On 24/02/15 06:27, Juergen Gross wrote:
On 02/19/2015 07:07 PM, David Vrabel wrote:
On 18/02/2015 06:51, Juergen Gross wrote:
+{
+unsigned long pfn;
+unsigned long area_start, area_end;
+unsigned i;
+
+for (i = 0; i < XEN_N_RESERVED_A
On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> This will later more easily let us unfold PARAVIRT and PARAVIRT_CLOCK
> from under CONFIG_XEN. All the XEN_PV* stuff is under the x86 universe.
> This is as per the agreed upon Xen Kconfig changes [0].
>
> [0] http://c
On Wed, 2015-02-25 at 15:34 +, Julien Grall wrote:
> Hi Frediano,
>
> On 25/02/15 15:28, Frediano Ziglio wrote:
> > HiSilison Hip04 platform use a slightly different version
>
> I honestly don't like the idea to copy the whole GIC-v2 drivers. It will
> require more maintenance for us.
Will i
>
> Hi Frediano,
>
> On 25/02/15 15:28, Frediano Ziglio wrote:
> > HiSilison Hip04 platform use a slightly different version
>
> I honestly don't like the idea to copy the whole GIC-v2 drivers. It
> will require more maintenance for us.
>
> Is there any way to introduce callbacks in the GICv2 c
On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> This lets us expose XEN_PVH and set what is required for it.
> This only exists on the x86 universe. This is as per the agreed
> upon Xen Kconfig changes [0].
>
> [0] http://comments.gmane.org/gmane.comp.emulators.xen.
On 2015-02-10 23:32, Paul Bolle wrote:
> On Tue, 2015-02-10 at 14:21 -0800, David Rientjes wrote:
>> We need an update to the MAINTAINERS file if "Yann E. MORIN"
>> isn't the active Kconfig maintainer anymore.
>
> Yes, we do. Michal, what update would you suggest?
I'll revert the patch that add
On Wed, 2015-02-25 at 10:35 -0500, D'Mita Levy wrote:
> Hello,
>
>
> I have made a naive attempt at compiling a modified version of
> Xentrace using RELEASE-4.5.0. After executing #make tools
> successfully, I retrieved the binary found in
> the /xen/dist/install/usr/local/bin/xentrace and attemp
>
> Hi Frediano,
>
> On 25/02/15 15:28, Frediano Ziglio wrote:
> > HiSilison Hip04 platform use a slightly different version
>
> I honestly don't like the idea to copy the whole GIC-v2 drivers. It
> will require more maintenance for us.
>
> Is there any way to introduce callbacks in the GICv2 c
Hello,
I have made a naive attempt at compiling a modified version of Xentrace
using RELEASE-4.5.0. After executing #make tools successfully, I retrieved
the binary found in the /xen/dist/install/usr/local/bin/xentrace and
attempted to run that on Xenserver. I get the error:
libxenctrl.so.4.5 can
Hi Frediano,
On 25/02/15 15:28, Frediano Ziglio wrote:
> HiSilison Hip04 platform use a slightly different version
I honestly don't like the idea to copy the whole GIC-v2 drivers. It will
require more maintenance for us.
Is there any way to introduce callbacks in the GICv2 code where the
hisilic
In fact: vnode_to_pnode is an array, not a mask; there was a
typo in the one about vmemrange; there was no indication
of the data directions.
Signed-off-by: Dario Faggioli
Cc: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Keir Fraser
Cc: Elena Ufimtseva
---
xen/include/public/domctl.h | 3
On Wed, 2015-02-25 at 15:20 +, Daniel P. Berrange wrote:
> On Wed, Feb 25, 2015 at 03:13:36PM +, Ian Campbell wrote:
> > On Wed, 2015-02-25 at 15:03 +, Daniel P. Berrange wrote:
> > > FWIW, this code in openstack was only added for benefit of s390
> > > architecture where apparently it
HiSilison Hip04 platform use a slightly different version
Signed-off-by: Frediano Ziglio
---
xen/arch/arm/Makefile| 2 +-
xen/arch/arm/gic-hip04.c | 788 +++
2 files changed, 789 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/arm/gic-h
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
This set of patches add Xen support for hip04-d01 platform (see
https://wiki.linaro.org/Boards/D01 for details).
Changes from v5:
- do not change gic-v2.c code but use a copy.
To be considered RFC, to see if better to use copy or other techniques.
Changes from v4:
- rebased to new version;
- re
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-hip04.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/
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-hip04.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index 9a7ed46..a1ae5
flight 35317 ovmf real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35317/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf 5 xen-boot fail REGR. vs. 33686
test-amd64-i386-pair 17 guest-migrate
On Wed, 2015-02-25 at 15:03 +, Daniel P. Berrange wrote:
> FWIW, this code in openstack was only added for benefit of s390
> architecture where apparently it is common to have hosts with
> CPUs offlined. Presumably you have to pay IBM for each extra
> CPU you turn online :)
Presumably :-)
OOI
In libxl_set_memory_target when setting the new maxmem, retain the same
offset on top of the current target. In the future the offset will
include memory allocated by QEMU for rom files.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- remove new_target_memkb <= 0 check.
Changes in v3:
-
On Wed, Feb 25, 2015 at 03:13:36PM +, Ian Campbell wrote:
> On Wed, 2015-02-25 at 15:03 +, Daniel P. Berrange wrote:
> > FWIW, this code in openstack was only added for benefit of s390
> > architecture where apparently it is common to have hosts with
> > CPUs offlined. Presumably you have t
On Mon, 2 Feb 2015, Ian Campbell wrote:
> On Thu, 2015-01-29 at 15:08 +, Stefano Stabellini wrote:
> > @@ -4775,6 +4781,14 @@ retry_transaction:
> > new_target_memkb = current_target_memkb + target_memkb;
> > } else
> > new_target_memkb = target_memkb - videoram;
> >
freemem_slack accounts for the amount of memory to be left free in the
system because empirical experiments seem to demonstrate that is needed
for "stability reasons".
As we don't have any actual data on these stability issues, remove it.
Signed-off-by: Stefano Stabellini
CC: mlati...@suse.com
C
LIBXL_MAXMEM_CONSTANT is used to increase the maxmem setting for a
domain by a constant amount. As it is not clear the reason why we should
be doing this, remove the constant.
Signed-off-by: Stefano Stabellini
CC: mlati...@suse.com
CC: ian.campb...@citrix.com
---
tools/libxl/libxl.c |
> -Ursprüngliche Nachricht-
> Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Gesendet: Dienstag, 24. Februar 2015 18:13
> An: Mayer, Kevin; xen-devel@lists.xen.org
> Betreff: Re: [Xen-devel] Branch Trace Storage for guests and VPMU
> initialization
>
> On 02/24/2015 10:27 AM, k
On Wed, Feb 25, 2015 at 10:24:37AM +0100, Dario Faggioli wrote:
> On Tue, 2015-02-24 at 13:10 +, Ian Campbell wrote:
> > On Tue, 2015-02-24 at 12:41 +, Anthony PERARD wrote:
>
> > > What libxl API those provide this information, if it exist?
> > >
> > > I found libxl_get_online_cpus() but
... when calculating how many pages to allocate fopr Dom0. This is
basically equivalent to the already present IOMMU related adjustment.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -132,6 +132,8 @@ struct vcpu *__init alloc_dom0_vcpu0(str
#i
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
tools/libxl/libxl.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c219f59..b394ee8 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -308,8 +308,7 @@
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
tools/libxl/gentypes.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index afd4eea..00816c0 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -642,6 +642,7 @@
We need a sentinel slot in the generated libxl_key_value_list.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
This should be backported to 4.5.
---
tools/libxl/libxl_json.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/l
The first two patches are bug fixes.
Other patches are used to make _dispose idempotent and NULL-tolerant.
Wei.
Wei Liu (7):
libxl: fix off-by-one error in JSON parser
gentest: make testidl valgrind clean
libxl: make some _dipose functions idempotent and tolerate NULL
gentypes: zero out
Free the JSON string after use to avoid memory leak. With this change
testidl is valgrind clean.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
tools/libxl/gentest.py | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/gentest.py b/tools/libx
Call _init and _dispose between 1 to 10 times on a type to test if _init
and _dispose are idempotent.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
tools/libxl/gentest.py | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/gentest.py b/too
Remove a redundant statement from parse_dom0_mem() and refuse bogus
ranges (with a separator other than a dash) passed to
parse_dom0_max_vcpus(). Fix coding style issues in the latter function
at the same time.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domai
On Thu, 2015-02-19 at 18:12 +, Julien Grall wrote:
> While it's easy to know which hardware IRQ is assigned to a domain, there
> is no way to know which vIRQ is allocated by Xen for a specific domain.
>
> Introduce a bitmap to keep track of every vIRQ used by a domain. This
> will be used late
These functions are not generated, so we need to do it by hand.
Functions list:
libxl_bitmap_dispose
libxl_string_list_dispose
libxl_key_value_list_dipose
libxl_cpuid_dispose
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
tools/libxl/libxl.c | 11 +--
tools/libx
Original the structure was memset to a poison value. That prevented
_dispose to be made idempotent. We should stop doing so.
Memseting the structure to 0 makes all pointers in structure become
NULL, which can be handled by free().
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
to
Non-anonymous allocations with this flag set should - for the purpose
of the availability check - be treated just like anonymous ones, as
they wouldn't lead to a reduction of ->outstanding_pages.
Signed-off-by: Jan Beulich
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -617,7 +61
Please ignore this series. I will send out another version that's
simpler.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
BTW, you should send this patch to net...@vger.kernel.org.
Have a look at Documentation/networking/netdev-FAQ.txt for more
information. Feel free to ask me any question if you have doubt.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://l
On Thu, 2015-02-19 at 16:20 +, Julien Grall wrote:
> Regardless the question,this patch look good to me. With the 2 nits I
> spotted on my previous email:
>
> Reviewed-by: Julien Grall
Thanks, applied both patches (with nits fixed)
>
> Regards,
>
__
offset and size are of type uint16_t so the %lu gives a warning
A %u specifier, the same used in size makes gcc happy
Signed-off-by: pedro
---
drivers/net/xen-netback/netback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xe
On Wed, Feb 25, 2015 at 03:27:13PM +0100, pedro wrote:
> offset and size are of type uint16_t so the %lu gives a warning
> A %u specifier, the same used in size makes gcc happy
>
> Signed-off-by: pedro
Acked-by: Wei Liu
Thanks for the patch.
One question though. Is "pedro" your real full name
On Wed, 25 Feb 2015, David Vrabel wrote:
> On 25/02/15 14:17, Stefano Stabellini wrote:
> > On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez"
> >>
> >> This unwraps XEN_BACKEND from depending on XEN_DOM0, it
> >> instead makes it depend on the possible x86 backends and
>
On 25/02/15 14:32, Ian Campbell wrote:
> On Thu, 2015-02-19 at 15:13 +, Ian Campbell wrote:
>> On Thu, 2015-02-19 at 14:42 +, Julien Grall wrote:
> Although, I think the debug message in bad_trap is useful to keep. It
> may be handy to have the HSR and the guest stack trace printed
1 - 100 of 187 matches
Mail list logo
