>>> On 15.01.15 at 22:00, wrote:
> On 01/15/15 11:42, Jan Beulich wrote:
> On 02.10.14 at 23:30, wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/hvm/vmware/cpuid.c
>>
>> Whether adding another subdirectory here is really the way to go
>> heavily depends on how much of this new code we really
>>> On 15.01.15 at 19:23, wrote:
> On 01/15/2015 08:15 AM, Tim Deegan wrote:
>> - Feature compatibilty/completeness. You pointed out yourself that
>> it doesn't work with nested HVM or migration. I think I'd have to
>> add mem_event/access/paging and PCI passthrough to the list of
>> featu
>>> On 15.01.15 at 21:38, wrote:
> On 01/15/2015 09:03 AM, Tim Deegan wrote:
>> At 13:26 -0800 on 09 Jan (1420806397), Ed White wrote:
>>> This is treated exactly like p2m_ram_rw, except that suppress_ve is not
>>> set in the EPTE.
>>
>> I don't think this is going to work -- you probably want to
flight 33424 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33424/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33402
Tests which did not succeed,
>>> On 15.01.15 at 22:00, wrote:
> On 01/15/2015 09:33 AM, Tim Deegan wrote:
>> Hi,
>>
>> Sorry for the fractured replies - my notes are confused about which
>> functions were defined where.
>>
>> At 13:26 -0800 on 09 Jan (1420806398), Ed White wrote:
>>> +bool_t p2m_change_altp2m_pfn(struct dom
在 2015/1/16 0:16, Don Slutz 写道:
On 01/15/15 05:20, Ian Campbell wrote:
On Thu, 2015-01-15 at 11:31 +0800, Zhenzhong Duan wrote:
Hi Maintainers,
We are facing issue collecting coredump using the xm dump mechanism
in Dom0.
We face couple of such issues daily, where the VMs panic s and the SA
Am 16.01.2015 um 00:09 schrieb Michael Ellerman:
> On Thu, 2015-01-15 at 09:58 +0100, Christian Borntraeger wrote:
>> ACCESS_ONCE does not work reliably on non-scalar types. For
>> example gcc 4.6 and 4.7 might remove the volatile tag for such
>> accesses during the SRA (scalar replacement of aggre
On Thu, 2015-01-15 at 21:06 +, Julien Grall wrote:
> QEMU upstream requires the use of pixman. When pixman is not present the
> system, the configure of QEMU will fail with:
>
> ERROR: pixman not present. Your options:
> (1) Preferred: Install the pixman devel package (any recent
>
HVM guests have always been confined to using the domain callback
via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications.
This is usually an IOAPIC vector and is only used if the event
channel is bound to vcpu 0.
PVHVM Linux uses a pre-defined interrupt vector for the event
channel upcall
>>> On 03.10.14 at 00:40, wrote:
> This is a new domain_create() flag, DOMCRF_vmware_port. It is
> passed to domctl as XEN_DOMCTL_CDF_vmware_port.
Can you explain why a HVM param isn't suitable here?
> This is both a more complete support then in currently provided by
> QEMU and/or KVM and less
On Fri, 2015-01-16 at 16:39 +0800, Zhenzhong Duan wrote:
> I am thinking if port some code from makedumpfile is possible and
> acceptable.
makedumpfile appears to be GPL, whereas libxc is LGPL, so if you wanted
to port code directly you would need permissions from the copyright
holders to re-lice
flight 33434 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33434/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-rumpuserxen-i386 5 xen-bootfail pass in 33416
test-amd64-amd64-rumpuserxen-amd64
On Thu, 15 Jan 2015, Don Slutz wrote:
> Now that Xen 4.5 has been released, I would like to see at least QEMU
> 2.2.0 in qemu-upstream-stable on the master branch.
Agreed
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hi Jan,
I found the restore process of the live migration is quit long, so I try to
find out what's going on.
By debugging, I found the most time consuming process is restore the VM's MTRR
MSR,
The process is done in the function hvm_load_mtrr_msr(), it will call the
memory_type_changed(), which
On 16/01/15 10:09, Paul Durrant wrote:
> HVM guests have always been confined to using the domain callback
> via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications.
> This is usually an IOAPIC vector and is only used if the event
> channel is bound to vcpu 0.
>
> PVHVM Linux uses a pre-def
On Thu, Jan 15, 2015 at 6:31 PM, Ed White wrote:
> On 01/15/2015 02:39 AM, Tamas K Lengyel wrote:
>>> There are ways of avoiding the
>>> single-step too, although I don't think that falls within the scope
>>> of this conversation.
>>>
>>> Ed
>>
>> I would be very interested in knowing how we can a
On 16/01/15 10:29, Li, Liang Z wrote:
> Hi Jan,
>
> I found the restore process of the live migration is quit long, so I try to
> find out what's going on.
> By debugging, I found the most time consuming process is restore the VM's
> MTRR MSR,
> The process is done in the function hvm_load_mtrr_m
On 15/01/15 16:18, Jan Beulich wrote:
>
> Wouldn't most of the changes up to here make a nice preparatory
> cleanup patch, easing review?
Yes, so...
> Leaving aside those mostly mechanical comments, content wise the
> patch looks good to me, but I'd hope for at least one other review.
,.. it mi
> -Original Message-
> From: Andrew Cooper
> Sent: 16 January 2015 10:39
> To: Paul Durrant; xen-devel@lists.xen.org
> Cc: Keir (Xen.org); David Vrabel; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v5] x86/hvm: Add per-vcpu evtchn upcalls
>
> On 16/01/15 10:09, Paul Durrant wrote:
> > HVM
Ian Jackson writes ("Re: [Xen-devel] [rumpuserxen test] 33416: regressions -
FAIL"):
...
> I can't easily rerun it by hand, but the cron job is rerunning it
> already. Also our automatic bisector is working on it.
xen.org writes ("[rumpuserxen test] 33434: tolerable FAIL - PUSHED"):
> flight 334
On Fri, Jan 16, 2015 at 10:14:12AM +, Ian Campbell wrote:
> On Fri, 2015-01-16 at 16:39 +0800, Zhenzhong Duan wrote:
> > I am thinking if port some code from makedumpfile is possible and
> > acceptable.
>
> makedumpfile appears to be GPL, whereas libxc is LGPL, so if you wanted
> to port code d
Julien Grall writes ("[PATCH v2 0/2] tools/configure: Add QEMU dependencies"):
> This small patch series replaces the patch [1] sent earlier.
Both:
Acked-by: Ian Jackson
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen
Ian Campbell writes ("Re: [PATCH v2 2/2] tools/configure: Check if pixman is
present on the system when building QEMU"):
> On Thu, 2015-01-15 at 21:06 +, Julien Grall wrote:
> > -dnl Glib 2.0 is only required when QEMU is built
> > +dnl Glib 2.0 and pixman are only required when QEMU is built
>>> On 16.01.15 at 11:46, wrote:
> On 16/01/15 10:29, Li, Liang Z wrote:
>> I found the restore process of the live migration is quit long, so I try to
> find out what's going on.
>> By debugging, I found the most time consuming process is restore the VM's
> MTRR MSR,
>> The process is done in t
>>> On 16.01.15 at 12:07, wrote:
>> From: Andrew Cooper
>> On 16/01/15 10:09, Paul Durrant wrote:
>> > +#define HVMOP_set_evtchn_upcall_vector 23
>> > +struct xen_hvm_set_evtchn_upcall_vector {
>> > +uint32_t vcpu;
>> > +uint8_t vector;
>> > +};
>> > +typedef struct xen_hvm_set_evtchn_upca
Hi Ian,
On 16/01/15 10:05, Ian Campbell wrote:
> On Thu, 2015-01-15 at 21:06 +, Julien Grall wrote:
>> QEMU upstream requires the use of pixman. When pixman is not present the
>> system, the configure of QEMU will fail with:
>>
>> ERROR: pixman not present. Your options:
>> (1) Prefer
On 16/01/15 11:54, Jan Beulich wrote:
On 16.01.15 at 11:46, wrote:
>> On 16/01/15 10:29, Li, Liang Z wrote:
>>> I found the restore process of the live migration is quit long, so I try to
>> find out what's going on.
>>> By debugging, I found the most time consuming process is restore the VM
This has no guest-visible change, but makes the Hypervisor side bounds
checking more simple.
Signed-off-by: Andrew Cooper
CC: Keir Fraser
CC: Jan Beulich
CC: Ian Campbell
CC: Stefano Stabellini
CC: Tim Deegan
---
There are no functional changes as a result of this patch, but I have an RFC
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 January 2015 11:59
> To: Andrew Cooper; Paul Durrant; xen-devel@lists.xen.org
> Cc: David Vrabel; Keir (Xen.org)
> Subject: RE: [Xen-devel] [PATCH v5] x86/hvm: Add per-vcpu evtchn upcalls
>
> >>> On 16.01.15 at
flight 33426 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33426/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-freebsd10-i386 7 freebsd-install fail like 33406
test-amd64-i386-freebsd10-amd6
On 15.01.15 09:58, Christian Borntraeger wrote:
> Folks,
>
> fyi, this is my current patch queue for the next merge window. It
> does contain a patch that will disallow ACCESS_ONCE on non-scalar
> types.
>
> The tree is part of linux-next and can be found at
> git://git.kernel.org/pub/scm/linux
>>> On 16.01.15 at 13:03, wrote:
> This has no guest-visible change, but makes the Hypervisor side bounds
> checking more simple.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
> There are no functional changes as a result of this patch, but I have an RFC
> improvement to suggest.
>
flight 33427 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33427/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-installfail like 9
test-amd64-amd64-xl-qemut-
From: Oleksandr Tyshchenko
Signed-off-by: Oleksandr Tyshchenko
---
docs/misc/arm/early-printk.txt | 1 +
xen/arch/arm/Rules.mk | 4 ++
xen/arch/arm/arm32/debug-rcar2.inc | 49 +
xen/include/asm-arm/rcar2-uart.h | 107 +
From: Iurii Konovalenko
The following patch series adds basic support needed for R-Car Gen2 evm boards.
Verified on Xen 4.5.0 stable on Lager board with and without early_printk.
Iurii Konovalenko (1):
xen/arm: Introduce support for Renesas R-Car Gen2 platform
Oleksandr Tyshchenko (2):
xen/
From: Iurii Konovalenko
Signed-off-by: Iurii Konovalenko
---
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/shmobile.c| 149 +++
xen/include/asm-arm/platforms/shmobile.h | 24 +
3 files changed, 174 insertions(+)
create mode 10
From: Oleksandr Tyshchenko
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Iurii Konovalenko
---
config/arm32.mk | 1 +
xen/drivers/char/Makefile | 1 +
xen/drivers/char/rcar2-uart.c | 376 ++
3 files changed, 378 insertions(+)
On Fri, 2015-01-16 at 13:05 +, Julien Grall wrote:
> Hello Iurii,
>
> Thanks for adding the support of a new board in Xen.
>
> On 16/01/15 12:50, Iurii Konovalenko wrote:
> > diff --git a/xen/include/asm-arm/rcar2-uart.h
> > b/xen/include/asm-arm/rcar2-uart.h
> > new file mode 100644
> > ind
Hello Iurii,
Thanks for adding the support of a new board in Xen.
On 16/01/15 12:50, Iurii Konovalenko wrote:
> diff --git a/xen/include/asm-arm/rcar2-uart.h
> b/xen/include/asm-arm/rcar2-uart.h
> new file mode 100644
> index 000..10a56fb
> --- /dev/null
> +++ b/xen/include/asm-arm/rcar2-uar
On 16/01/15 13:08, Ian Campbell wrote:
> I'd prefer the naming (here and for the main driver) to be as far to the
> right of that list as possible.
All the UART headers in xen/ and asm-arm/ are called myuart-uart.h.
I think it's better if we keep the same convention everywhere.
Regards,
--
Jul
On Fri, 2015-01-16 at 13:11 +, Julien Grall wrote:
> On 16/01/15 13:08, Ian Campbell wrote:
> > I'd prefer the naming (here and for the main driver) to be as far to the
> > right of that list as possible.
>
> All the UART headers in xen/ and asm-arm/ are called myuart-uart.h.
>
> I think it's
Hi Iurii,
On 16/01/15 12:50, Iurii Konovalenko wrote:
> +static int __init rcar2_uart_init(struct dt_device_node *dev,
> + const void *data)
> +{
> +const char *config = data;
> +struct rcar2_uart *uart;
> +int res;
> +u64 addr, size;
> +
> +if (
Hi all.
Let me explain.
The Renesas R-Car Gen2 is a family of SoCs (R-Car H2, M2, etc.).
The "Lager" is a name of development board based on R-Car H2 SoC.
The UART IP block named SCIF (Serial Communication Interface with FIFO)
is common for all SoCs in R-Car Gen2 family.
On Fri, Jan 16, 2015 at
On Fri, 2015-01-16 at 15:26 +0200, Oleksandr Tyshchenko wrote:
> Hi all.
>
> Let me explain.
>
>
> The Renesas R-Car Gen2 is a family of SoCs (R-Car H2, M2, etc.).
> The "Lager" is a name of development board based on R-Car H2 SoC.
> The UART IP block named SCIF (Serial Communication Interface
flight 33430 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33430/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 8 guest-stop fail REGR. vs. 33406
test-amd64-amd64-xl-qe
flight 33443 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33443/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 33422
build-armhf-libvirt
Hello,
On Tue, 2015-01-13 at 17:00 +, Daniel P. Berrange wrote:
> +# define VIR_WARNINGS_NO_PRINTF \
> +_Pragma ("GCC diagnostic push") \
> +_Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute=format\"")
Xen automated tests are failing to build on all architectures with:
Hi Iurii,
On 16/01/15 12:50, Iurii Konovalenko wrote:
> From: Iurii Konovalenko
>
> Signed-off-by: Iurii Konovalenko
> ---
> xen/arch/arm/platforms/Makefile | 1 +
> xen/arch/arm/platforms/shmobile.c| 149
> +++
> xen/include/asm-arm/platforms/sh
On Fri, Jan 16, 2015 at 01:58:27PM +, Ian Campbell wrote:
> Hello,
>
> On Tue, 2015-01-13 at 17:00 +, Daniel P. Berrange wrote:
> > +# define VIR_WARNINGS_NO_PRINTF \
> > +_Pragma ("GCC diagnostic push") \
> > +_Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute=format\"")
>
>
This enum was used for matching a specific device and not to get the
type of device.
Hence the name device_type will be used for another purpose later.
Signed-off-by: Julien Grall
---
xen/arch/arm/device.c| 4 ++--
xen/include/asm-arm/device.h | 8
2 files changed, 6 insertions
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
---
xen/arch/arm/gic-v2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..f149e09 100644
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
---
xen/arch/arm/vgic-v2.c | 1 -
xen/arch/arm/vgic-v3.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/xen/arch/
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
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 drivers 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 current SMMU driver has completly diverged. That makes me hard to
maintain.
Signed-off-by: Julien Grall
---
xen/drivers/passthrough/arm/Makefile |1 -
xen/drivers/passthrough/arm/smmu.c | 1784 --
2 files changed, 1785 deletions(-)
delete mode 100644 xe
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
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
to a context should be less than the number of SMR groups used so fa
Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3.
It's a basic copy of the Linux SMMU drivers code. No Xen code has yet been added
and not build.
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
---
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 that
is already in use.
So better check for duplicates when DT info
Xen is currently using list a compatible string to know if the driver
can use device node. This leads to have double definition in the GIC
code.
Futhermore Linux drivers is using dt_match_node (actually called of_device_id
in Linux) to list device supported by the drivers.
Signed-off-by: Julien G
Some drivers may want to configure differently the device depending on
the compatible string.
Also modify the return type of dt_match_node to return the matching
structure.
Signed-off-by: Julien Grall
---
xen/arch/arm/platform.c | 2 +-
xen/common/device_tree.c | 12 ++--
xe
It is no good idea to have bitfields in the same byte which are modified
with different locks held (or, in this case, one with lock and one
without). Use at least bytes for this purpose.
Signed-off-by: Juergen Gross
diff -r 3feb5ddb5434 drivers/xen/scsifront/common.h
--- a/drivers/xen/scsifront/
Hi everyone,
I just wanted to let you know that
a) the website for the developer summit is up and running now :
http://events.linuxfoundation.org/events/xen-project-developer-summit/
b) the CfP is also open now at
http://events.linuxfoundation.org/events/xen-project-developer-summit/program/cfp
On 16/01/15 11:17, Ian Jackson wrote:
The latter is the GPF turning out to be unreproducible.
I guess we should keep an eye out in case it turns out to be a race
rather than a cosmic ray.
I do not believe in cosmic rays.
Some notes in case it resurfaces:
1) the topmost caller address appears
On Fri, 2015-01-16 at 14:19 +, Daniel P. Berrange wrote:
> On Fri, Jan 16, 2015 at 01:58:27PM +, Ian Campbell wrote:
> > Hello,
> >
> > On Tue, 2015-01-13 at 17:00 +, Daniel P. Berrange wrote:
> > > +# define VIR_WARNINGS_NO_PRINTF \
> > > +_Pragma ("GCC diagnostic push") \
> > >
>>> On 16.01.15 at 15:24, wrote:
> ---
> xen/common/device.c | 21 +
> xen/common/device_tree.c | 3 +++
Is there a Makefile change missing here?
> --- /dev/null
> +++ b/xen/common/device.c
> @@ -0,0 +1,21 @@
> +#include
> +#include
> +
> +void device_initia
Hi Jan,
On 16/01/15 14:59, Jan Beulich wrote:
On 16.01.15 at 15:24, wrote:
>> ---
>> xen/common/device.c | 21 +
>> xen/common/device_tree.c | 3 +++
>
> Is there a Makefile change missing here?
No. The file common/device.c should not be there. I drop fo
On Fri, Jan 16, 2015 at 02:47:42PM +, Ian Campbell wrote:
> On Fri, 2015-01-16 at 14:19 +, Daniel P. Berrange wrote:
> > On Fri, Jan 16, 2015 at 01:58:27PM +, Ian Campbell wrote:
> > > Hello,
> > >
> > > On Tue, 2015-01-13 at 17:00 +, Daniel P. Berrange wrote:
> > > > +# define VI
>>> On 16.01.15 at 15:24, 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 'struct pci_dev'
> b
Hello Manish,
recently Clark Laughlin (CC'ed) got OpenStack, libvirt and Xen all
working together on ARM. He wrote the following wiki page:
https://wiki.linaro.org/OpenStack/DevstackOnXenARM
Cheers,
Stefano
On Fri, 16 Jan 2015, Jaggi, Manish wrote:
> Hi Jim,
>
>
> I am trying to run libvirtd
Hi, Julien.
On Fri, Jan 16, 2015 at 4:08 PM, Julien Grall
wrote:
> Hi Iurii,
>
> On 16/01/15 12:50, Iurii Konovalenko wrote:
>> From: Iurii Konovalenko
>>
>> Signed-off-by: Iurii Konovalenko
>> ---
>> xen/arch/arm/platforms/Makefile | 1 +
>> xen/arch/arm/platforms/shmobile.c
On 16/01/15 15:29, Iurii Konovalenko wrote:
>> Is there any reason that this code diverge?
>>
>
> Linux kernel 3.14-ltsi, which I used as a reference, use CNTFID0
> in file arch/arm/mach-shmobile/setup-rcar-gen2.c:
> iowrite32(freq, base + CNTFID0);
Which seems different from upstream:
1. /* Upd
> -Original Message-
> From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com]
> Sent: Thursday, January 15, 2015 11:49 PM
> To: Xu, Quan; qemu-de...@nongnu.org
> Cc: stefano.stabell...@eu.citrix.com; xen-devel@lists.xen.org
> Subject: Re: [Qemu-devel] [v3 4/5] Qemu-Xen-vTPM: Qemu vTPM xe
On Fri, Jan 16, 2015 at 3:19 PM, Julien Grall
wrote:
> Hi Iurii,
>
Hi Julien
>
> On 16/01/15 12:50, Iurii Konovalenko wrote:
> > +static int __init rcar2_uart_init(struct dt_device_node *dev,
> > + const void *data)
> > +{
> > +const char *config = data;
> > +
On 01/07/2015 04:12 AM, Jan Beulich wrote:
On 06.01.15 at 14:41, wrote:
On 06/01/15 02:18, Boris Ostrovsky wrote:
Instead of copying data for each field in xen_sysctl_topologyinfo separately
put cpu/socket/node into a single structure and do a single copy for each
processor.
There is also no
Signed-off-by: Stefano Stabellini
diff --git a/Config.mk b/Config.mk
index 0e22057..4745b85 100644
--- a/Config.mk
+++ b/Config.mk
@@ -252,7 +252,7 @@ QEMU_TRADITIONAL_URL ?=
git://xenbits.xen.org/qemu-xen-unstable.git
SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
endif
OVMF_UPST
>>> On 16.01.15 at 16:56, wrote:
> On 01/07/2015 04:12 AM, Jan Beulich wrote:
> On 06.01.15 at 14:41, wrote:
>>> On 06/01/15 02:18, Boris Ostrovsky wrote:
Instead of copying data for each field in xen_sysctl_topologyinfo
separately
put cpu/socket/node into a single structure a
Stefano Stabellini writes ("[PATCH] Switch QEMU_UPSTREAM_REVISION back to
master"):
> Signed-off-by: Stefano Stabellini
>
> diff --git a/Config.mk b/Config.mk
> index 0e22057..4745b85 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -252,7 +252,7 @@ QEMU_TRADITIONAL_URL ?=
> git://xenbits.xen.or
On Fri, 16 Jan 2015, Andrew Cooper wrote:
> This has no guest-visible change, but makes the Hypervisor side bounds
> checking more simple.
>
> Signed-off-by: Andrew Cooper
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Ian Campbell
> CC: Stefano Stabellini
> CC: Tim Deegan
>
For the tiny arm pa
On 01/16/2015 11:06 AM, Jan Beulich wrote:
On 16.01.15 at 16:56, wrote:
On 01/07/2015 04:12 AM, Jan Beulich wrote:
On 06.01.15 at 14:41, wrote:
On 06/01/15 02:18, Boris Ostrovsky wrote:
Instead of copying data for each field in xen_sysctl_topologyinfo separately
put cpu/socket/node into a s
On Fri, 2015-01-16 at 16:06 +, Jan Beulich wrote:
> >>> On 16.01.15 at 16:56, wrote:
> > On 01/07/2015 04:12 AM, Jan Beulich wrote:
> > On 06.01.15 at 14:41, wrote:
> >>> On 06/01/15 02:18, Boris Ostrovsky wrote:
> Instead of copying data for each field in xen_sysctl_topologyinfo
>
I tried to add instruction: asm volatile("mcr p15, 0, %0, c14, c0, 0" : :
"r" (freq));
Also I tried to write it via Xen API: WRITE_SYSREG32(freq, CNTFRQ_EL0);
But unfortunately Xen fails on both this instructions with "Undefined
instruction" exception.
You can see log in attachment.
Could you plea
Hi,
I'm trying to measure number of cycles for hypercalls.
I'm working on ARM v7 and v8.
Xentrace seems to be a right tool to use according to this discussion.
http://lists.xen.org/archives/html/xen-devel/2008-10/msg00480.html
However when I ran it on ARM, it gave an error.
The error is the same
add_boot_module is calling a function which lies in the init section.
Furthermore, it's only used during Xen boot.
Signed-off-by: Julien Grall
---
xen/arch/arm/setup.c| 6 +++---
xen/include/asm-arm/setup.h | 8
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/
The code to build DOM0 is only used during Xen boot.
Signed-off-by: Julien Grall
---
xen/arch/arm/domain_build.c | 66 ++---
xen/include/asm-arm/setup.h | 2 +-
2 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b
The code to load the kernel is only used when Xen builds dom0. It
happens during the boot.
Signed-off-by: Julien Grall
---
xen/arch/arm/kernel.c | 30 +++---
xen/arch/arm/kernel.h | 4 ++--
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/xen/arch/arm/ker
The function is calling device_is_compatible which lies in init section
and is only called during Xen boot.
Signed-off-by: Julien Grall
---
xen/arch/arm/device.c| 2 +-
xen/include/asm-arm/device.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/device
Hello,
This small series add/remove __init on different functions. This allow Xen to
free around 8Kb more of memory after it has finished to boot.
Xen size in memory before to free init section: 1029Kb
Freed memory init: 288Kb
Regards,
Julien Grall (6):
arm/setup: Add missing __init to add_bo
>>> On 16.01.15 at 17:14, wrote:
> On 01/16/2015 11:06 AM, Jan Beulich wrote:
> On 16.01.15 at 16:56, wrote:
>>> On 01/07/2015 04:12 AM, Jan Beulich wrote:
>>> On 06.01.15 at 14:41, wrote:
> On 06/01/15 02:18, Boris Ostrovsky wrote:
>> Instead of copying data for each field in xe
The callbacks init_time and specific_mapping are respectively used
during timer initialization and DOM0 building. These 2 taks only
happen during Xen boot.
Signed-off-by: Julien Grall
---
xen/arch/arm/platforms/exynos5.c | 4 ++--
xen/arch/arm/platforms/omap5.c | 4 ++--
xen/arch/arm
When CPU hotplug will be supported, it will require to bring up a CPU.
Signed-off-by: Julien Grall
---
I'm not sure if we should flag these functions with __cpuinit. The
define doesn't do anything.
---
xen/arch/arm/arm32/smpboot.c | 4 ++--
xen/arch/arm/platform.c | 2 +-
xen/arch/arm/smp
Hi all
I`m trying to track code execution with page granularity by setting the access
rights in the EPT to not executable on Xen 4.4.1.
The idea is as follows:
According to the intel manual "A reference using a guest-physical address
whose translation encounters an EPT paging-structure that is
>>> On 16.01.15 at 11:09, wrote:
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -160,6 +160,7 @@ struct hvm_vcpu {
> } u;
>
> struct tasklet assert_evtchn_irq_tasklet;
> +u8 evtchn_upcall_vector;
>
> struct nestedvcpu
On 16/01/15 16:20, Julien Grall wrote:
> add_boot_module is calling a function which lies in the init section.
> Furthermore, it's only used during Xen boot.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/setup.c| 6 +++---
> xen/include/asm-arm/setup.h | 8
> 2 files chang
On 16/01/15 16:17, Iurii Konovalenko wrote:
> I tried to add instruction: asm volatile("mcr p15, 0, %0, c14, c0, 0" :
> : "r" (freq));
> Also I tried to write it via Xen API: WRITE_SYSREG32(freq, CNTFRQ_EL0);
>
> But unfortunately Xen fails on both this instructions with "Undefined
> instruction"
On 16/01/15 16:28, Andrew Cooper wrote:
> On 16/01/15 16:20, Julien Grall wrote:
>> add_boot_module is calling a function which lies in the init section.
>> Furthermore, it's only used during Xen boot.
>>
>> Signed-off-by: Julien Grall
>> ---
>> xen/arch/arm/setup.c| 6 +++---
>> xen/incl
On 01/16/2015 11:20 AM, Jan Beulich wrote:
On 16.01.15 at 17:14, wrote:
On 01/16/2015 11:06 AM, Jan Beulich wrote:
On 16.01.15 at 16:56, wrote:
On 01/07/2015 04:12 AM, Jan Beulich wrote:
On 06.01.15 at 14:41, wrote:
On 06/01/15 02:18, Boris Ostrovsky wrote:
Instead of copying data for ea
>>> On 16.01.15 at 17:16, wrote:
> On Fri, 2015-01-16 at 16:06 +, Jan Beulich wrote:
>> >>> On 16.01.15 at 16:56, wrote:
>> > On 01/07/2015 04:12 AM, Jan Beulich wrote:
>> > On 06.01.15 at 14:41, wrote:
>> >>> On 06/01/15 02:18, Boris Ostrovsky wrote:
>> Instead of copying data for
On Fri, 2015-01-16 at 16:34 +, Jan Beulich wrote:
> >>> On 16.01.15 at 17:16, wrote:
> > On Fri, 2015-01-16 at 16:06 +, Jan Beulich wrote:
> >> >>> On 16.01.15 at 16:56, wrote:
> >> > On 01/07/2015 04:12 AM, Jan Beulich wrote:
> >> > On 06.01.15 at 14:41, wrote:
> >> >>> On 06/01/15
1 - 100 of 151 matches
Mail list logo
