>>> On 19.05.15 at 08:47, wrote:
> On Tue, May 19, 2015 at 07:28:49AM +0100, Jan Beulich wrote:
>> >>> On 19.05.15 at 08:12, wrote:
>> > On Mon, May 18, 2015 at 02:21:40PM +0100, Jan Beulich wrote:
>> >> >>> On 08.05.15 at 10:56, wrote:
>> >> > @@ -112,6 +115,8 @@ static int __devinit MP_process
>>> On 18.05.15 at 18:19, wrote:
> On 05/18/2015 11:39 AM, Jan Beulich wrote:
> On 08.05.15 at 23:06, wrote:
>>> --- a/xen/arch/x86/hvm/svm/vpmu.c
>>> +++ b/xen/arch/x86/hvm/svm/vpmu.c
>>> @@ -45,6 +45,7 @@ static unsigned int __read_mostly num_counters;
>>> static const u32 __read_mostly *
>>> On 18.05.15 at 18:12, wrote:
> On 05/18/2015 11:15 AM, Jan Beulich wrote:
> On 08.05.15 at 23:06, wrote:
>>> +/*
>>> + * Architecture-specific information describing state of the processor at
>>> + * the time of PMU interrupt.
>>> + * Fields of this structure marked as RW for guest can on
On Tue, May 19, 2015 at 07:28:49AM +0100, Jan Beulich wrote:
> >>> On 19.05.15 at 08:12, wrote:
> > On Mon, May 18, 2015 at 02:21:40PM +0100, Jan Beulich wrote:
> >> >>> On 08.05.15 at 10:56, wrote:
> >> > @@ -112,6 +115,8 @@ static int __devinit MP_processor_info_x(struct
> >> > mpc_config_proc
On 2015/5/19 4:00, Wei Liu wrote:
On Thu, May 14, 2015 at 04:27:45PM +0800, Chen, Tiejun wrote:
On 2015/5/11 19:32, Wei Liu wrote:
On Mon, May 11, 2015 at 04:09:53PM +0800, Chen, Tiejun wrote:
On 2015/5/8 22:43, Wei Liu wrote:
Sorry for the late review. This series fell through the crack.
>>> On 18.05.15 at 20:39, wrote:
> On 18/05/15 13:46, Jan Beulich wrote:
>> This is needed as stacks are going to become non-executable. Use
>> separate stub pages (shared among suitable CPUs on the same node)
>> instead.
>>
>> Signed-off-by: Jan Beulich
>
> Can you please include a description
>>> On 19.05.15 at 08:12, wrote:
> On Mon, May 18, 2015 at 02:21:40PM +0100, Jan Beulich wrote:
>> >>> On 08.05.15 at 10:56, wrote:
>> > @@ -112,6 +115,8 @@ static int __devinit MP_processor_info_x(struct
>> > mpc_config_processor *m,
>> > {
>> >int ver, apicid, cpu = 0;
>> >
>> > + to
flight 56717 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56717/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866
build-i386-rumpuserxe
struct timeval uses a 32-bit field for representing seconds,
which will overflow in the year 2038 and beyond. This patch replaces
struct timeval with 64-bit ktime_t which is 2038 safe.
The patch is part of a larger effort to remove instances of
32-bit timekeeping variables (timeval, time_t and time
On Mon, May 18, 2015 at 02:21:40PM +0100, Jan Beulich wrote:
> >>> On 08.05.15 at 10:56, wrote:
> > --- a/xen/arch/x86/mpparse.c
> > +++ b/xen/arch/x86/mpparse.c
> > @@ -64,6 +64,9 @@ unsigned int __read_mostly boot_cpu_physical_apicid =
> > BAD_APICID;
> > static unsigned int __devinitdata num_
Hi,
I'd like to support the assignment of on chip RAMs to guests, starting with
dom0.
The mmio-sram compatible device kinda works already but the 2nd stage MMU
mapping is done with DEVICE memory attributes. This doesn't work well for
SRAMs for several reasons (e.g performance, alignment checks e
flight 56679 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56679/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail in 56637 REGR.
vs. 5028
flight 56677 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56677/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56589
Regressions which are
>>> On 5/18/2015 at 10:30 PM, in message
<20150518143008.ge9...@zion.uk.xensource.com>, Wei Liu
wrote:
> On Mon, May 18, 2015 at 03:23:38PM +0100, Ian Jackson wrote:
> > Chunyan Liu writes ("[PATCH V3 2/6] libxl_read_file_contents: fix reading
> sysfs file"):
> > > Sysfs file has size=4096
>>> On 5/19/2015 at 02:07 AM, in message
<20150518180724.gh9...@zion.uk.xensource.com>, Wei Liu
wrote:
> (I look at overall code structure this pass. I haven't done a line by
> line review.)
>
> On Sun, Apr 19, 2015 at 11:50:49AM +0800, Chunyan Liu wrote:
> > Add pvusb APIs, including:
>
On 2015/5/19 3:17, Wei Liu wrote:
On Fri, May 15, 2015 at 09:52:23AM +0800, Chen, Tiejun wrote:
[...]
...
B has the form C<[KEY=VALUE,KEY=VALUE,...> where:
=over 4
=item B
Possible Bs are:
=over 4
=item B
Currently we just have one type. "host" means all reserved device memory on
this
flight 56673 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56673/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect
test-amd64-amd64-pair
Dear Dario
Thanks for feedback on the comment
In O.S. it is scheduling of processes where equal priority jobs are always
handled with FCFS.
credit scheduler also follows same thing where equal priority VCPU s are
scheduled with FCFS.
In Credit Scheduler there are three priorities BOOST,UNDER,OVER
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Tuesday, May 19, 2015 4:00 AM
>
> On Thu, May 14, 2015 at 04:27:45PM +0800, Chen, Tiejun wrote:
> > On 2015/5/11 19:32, Wei Liu wrote:
> > >On Mon, May 11, 2015 at 04:09:53PM +0800, Chen, Tiejun wrote:
> > >>On 2015/5/8 22:43, Wei Liu wrote:
> >
On 18/05/2015 19:18, George Dunlap wrote
> On Fri, May 15, 2015 at 8:46 AM, Wang, Wei W
> wrote:
> >> > Do you have any comments on this version?
> >>
> >> Eventually I will. But as recently noted elsewhere, there are way too
> >> many things needing review right now, and I've got things other tha
On Mon, 18 May 2015, Ian Campbell wrote:
> On Mon, 2015-05-18 at 10:49 +0100, George Dunlap wrote:
> > Is there really no way to start up a qdisk process after the domain is
> > created? The qdisk process doesn't actually need to do any emulation,
> > after all -- it's just acting as a backend, ri
flight 56671 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56671/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail
REGR. vs. 56492
test-amd64-i386-
On 05/18/2015 08:38 AM, Ian Campbell wrote:
On Fri, 2015-05-15 at 10:39 +0100, Ian Campbell wrote:
The header file defining these SIDs is buried in the hypervisor source
tree (xen/xsm/flask/include/flask.h) and is only generated during a build
with XSM enabled. It may be simpler to define the v
flight 5 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/5/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 14 guest-localmigrate fail REGR. vs. 56375
test-amd64-amd64-xl
Dario,
Sorry I forgot to CC you when I sent this. :-/
Wei.
On Mon, May 18, 2015 at 04:34:48PM +0100, Wei Liu wrote:
> Boris discovered that HVM vNUMA didn't actually work. This patch series fixes
> that.
>
> The first patch is a prerequisite patch for the actual fixes. The second patch
> is to
On Thu, May 14, 2015 at 04:27:45PM +0800, Chen, Tiejun wrote:
> On 2015/5/11 19:32, Wei Liu wrote:
> >On Mon, May 11, 2015 at 04:09:53PM +0800, Chen, Tiejun wrote:
> >>On 2015/5/8 22:43, Wei Liu wrote:
> >>>Sorry for the late review. This series fell through the crack.
> >>>
> >>
> >>Thanks for you
On Fri, May 15, 2015 at 09:52:23AM +0800, Chen, Tiejun wrote:
[...]
>
>
> ...
>
> B has the form C<[KEY=VALUE,KEY=VALUE,...> where:
>
> =over 4
>
> =item B
>
> Possible Bs are:
>
> =over 4
>
> =item B
>
> Currently we just have one type. "host" means all reserved device memory on
> this pl
On 05/18/2015 04:34 AM, Michal Privoznik wrote:
On 09.05.2015 00:00, Jim Fehlig wrote:
This series fixes several bugs related to SPICE parsing and formatting
code in xenconfig. The bugs are mostly due to misinterpretation of the
Xen documenation, which I failed to notice when reviewing the init
flight 56662 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56662/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail in 56626
pass in 56662
test-amd64-i386-freebsd1
On 18/05/15 13:46, Jan Beulich wrote:
> This is needed as stacks are going to become non-executable. Use
> separate stub pages (shared among suitable CPUs on the same node)
> instead.
>
> Signed-off-by: Jan Beulich
Can you please include a description of how you intend the stubs to
function, and
(I look at overall code structure this pass. I haven't done a line by
line review.)
On Sun, Apr 19, 2015 at 11:50:49AM +0800, Chunyan Liu wrote:
> Add pvusb APIs, including:
> - attach/detach (create/destroy) virtual usb controller.
> - attach/detach usb device
> - list usb controller and usb d
Il 18/05/2015 18:16, Ian Jackson ha scritto:
Fabio Fantoni writes ("[PATCH v2][RFC] libxl: Add AHCI support for upstream
qemu"):
If enabled adds ich9 disk controller in ahci mode and uses it with
upstream qemu to emulate disks instead of ide.
I'm sorry for perhaps querying the obvious, but why
Il 18/05/2015 17:53, Wei Liu ha scritto:
On Thu, May 14, 2015 at 01:11:13PM +0200, Fabio Fantoni wrote:
Usage:
ahci=0|1 (default=0)
If enabled adds ich9 disk controller in ahci mode and uses it with
upstream qemu to emulate disks instead of ide.
Is ICH9 available in our default setup?
Why do
Il 18/05/2015 17:43, Wei Liu ha scritto:
On Fri, May 15, 2015 at 01:54:32PM +0200, Fabio Fantoni wrote:
NOTES:
This patch is a only a fast draft for testing.
Some tests result:
At xl create cdrom empty or not are both working, xl cd-insert is
working, xl cd-eject seems working but on xl comman
Il 18/05/2015 13:24, George Dunlap ha scritto:
On Fri, May 15, 2015 at 12:54 PM, Fabio Fantoni wrote:
NOTES:
This patch is a only a fast draft for testing.
Some tests result:
At xl create cdrom empty or not are both working, xl cd-insert is
working, xl cd-eject seems working but on xl command
QEMU upstream has been the default for several releases. The only
setting described in that document is no longer required.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Tim Deegan
Cc: Anthony Perard
---
docs/misc/qemu-upstream_howto_use_it.mar
Hi Julien,
On 15 May 2015 at 21:21, Julien Grall wrote:
> Until recently, a maintenance IRQ was requested for any IRQ injected to
> the guest on x-gene platform.
>
> The commit 50dcb3de603927db2fd87ba09e29c817415aaa44 "xen: arm: X-Gene Storm
> check GIC DIST address for EOI quirk" disable the qui
flight 56660 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56660/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 15
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 503
On 05/18/2015 11:39 AM, Jan Beulich wrote:
On 08.05.15 at 23:06, wrote:
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -45,6 +45,7 @@ static unsigned int __read_mostly num_counters;
static const u32 __read_mostly *counters;
static const u32 __read_mostly *ctrls;
st
Hi Ian,
On 15 May 2015 at 21:35, Ian Campbell wrote:
> On Fri, 2015-05-15 at 16:51 +0100, Julien Grall wrote:
>> The commit 50dcb3de603927db2fd87ba09e29c817415aaa44 "xen: arm: X-Gene Storm
>> check GIC DIST address for EOI quirk" disable the quirk for boards using
>> the new firmware.
>
> That re
Fabio Fantoni writes ("[PATCH v2][RFC] libxl: Add AHCI support for upstream
qemu"):
> If enabled adds ich9 disk controller in ahci mode and uses it with
> upstream qemu to emulate disks instead of ide.
I'm sorry for perhaps querying the obvious, but why is this a good
idea ? I think the underlyi
On 05/18/2015 11:15 AM, Jan Beulich wrote:
On 08.05.15 at 23:06, wrote:
--- /dev/null
+++ b/xen/include/public/arch-x86/pmu.h
@@ -0,0 +1,122 @@
+#ifndef __XEN_PUBLIC_ARCH_X86_PMU_H__
+#define __XEN_PUBLIC_ARCH_X86_PMU_H__
+
+/* x86-specific PMU definitions */
+
+/* AMD PMU registers and structu
On 18/05/15 16:30, Ian Campbell wrote:
> # Major External Consumers of `libxenctrl`
>
> * qemu
> * kexec tools
> * in guest tools e.g. users of `libxenstore`, `libvchan`, and by
> extension `grant table` and `event channel` functionality. NB:
> `libxenstore` is already `SSU` or `SSS` (XXX?)
>
>
On 12/05/15 18:18, Joao Martins wrote:
> It allows a newly allocated skb to reuse the gref taken from the
> pending_ring, which means xennet will grant the pages once and release
> them only when freeing the device. It changes how netfront handles news
> skbs to be able to reuse the allocated pages
On Thu, May 14, 2015 at 01:11:13PM +0200, Fabio Fantoni wrote:
> Usage:
> ahci=0|1 (default=0)
>
> If enabled adds ich9 disk controller in ahci mode and uses it with
> upstream qemu to emulate disks instead of ide.
Is ICH9 available in our default setup?
Why do we not always enable AHCI?
> It d
>>> On 18.05.15 at 17:30, wrote:
> `libxenctrl` today exposes many symbols which look to be internal. We
> should consider also reducing that set by using
> `__attribute__((visibility("hidden")))`.
Or a version script?
Jan
___
Xen-devel mailing list
On 12/05/15 18:18, Joao Martins wrote:
> Instead of grant/revoking the buffer related to the skb, it will use
> an already granted page and memcpy to it. The grants will be mapped
> by xen-netback and reused overtime, but only unmapped when the vif
> disconnects, as opposed to every packet.
>
> T
On 12/05/15 18:18, Joao Martins wrote:
> "feature-persistent" check on xenbus for persistent grants
> support on the backend.
You can't expose/check for this feature until you actually support it.
This should probably be the last patch.
David
___
Xen-d
>>> On 18.05.15 at 17:33, wrote:
> On 18/05/15 11:16, Jan Beulich wrote:
> On 14.05.15 at 13:21, wrote:
>>> void _spin_lock(spinlock_t *lock)
>>> {
>>> +spinlock_tickets_t tickets = { .tail = 1, };
>>
>> This breaks the build on gcc 4.3.x (due to tail being a member of an
>> unnamed st
On 12/05/15 18:18, Joao Martins wrote:
> Refactors how grants are claimed/released/revoked by moving that code
> into claim_grant and release_grant helpers routines that can be shared
> in both TX/RX path.
Reviewed-by: David Vrabel
But should this be generic? Is it useful to other frontends? A
On 12/05/15 18:18, Joao Martins wrote:
> Refactors a little bit how grants are stored by moving
> grant_rx_ref/grant_tx_ref and grant_tx_page to its
> own structure, namely struct grant.
Reviewed-by: David Vrabel
Although...
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
On Fri, May 15, 2015 at 01:54:32PM +0200, Fabio Fantoni wrote:
> NOTES:
> This patch is a only a fast draft for testing.
>
> Some tests result:
> At xl create cdrom empty or not are both working, xl cd-insert is
> working, xl cd-eject seems working but on xl command in linux hvm domU
> return qmp
Make the setup process similar to PV counterpart. That is, to allocate a
P2M array that covers the whole memory range and start from there. This
is clearer than using an array with no holes in it.
Also the dummy layout should take MMIO hole into consideration. We might
end up having two vmemranges
No functional changes introduced.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
tools/libxc/xc_hvm_build_x86.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index
>>> On 08.05.15 at 23:06, wrote:
> --- a/xen/arch/x86/hvm/svm/vpmu.c
> +++ b/xen/arch/x86/hvm/svm/vpmu.c
> @@ -45,6 +45,7 @@ static unsigned int __read_mostly num_counters;
> static const u32 __read_mostly *counters;
> static const u32 __read_mostly *ctrls;
> static bool_t __read_mostly k7_coun
On 18/05/15 11:16, Jan Beulich wrote:
On 14.05.15 at 13:21, wrote:
>> void _spin_lock(spinlock_t *lock)
>> {
>> +spinlock_tickets_t tickets = { .tail = 1, };
>
> This breaks the build on gcc 4.3.x (due to tail being a member of an
> unnamed structure member of a union).
I don't have a
When building HVM guests, originally some fields of xc_hvm_build_args
are filled in xc_hvm_build (and buried in the wrong function), some are
set in libxl__build_hvm before passing xc_hvm_build_args to
xc_hvm_build. This is fragile.
After examining the code in xc_hvm_build that sets those fields,
Boris discovered that HVM vNUMA didn't actually work. This patch series fixes
that.
The first patch is a prerequisite patch for the actual fixes. The second patch
is to help debugging. The fixes are in the last two patches, which can be
squashed into one if necessary.
Wei.
Wei Liu (4):
libxc/
This patch does two thing:
The original code erroneously fills in xc_hvm_build_args before
generating vmemranges. The effect is that guest memory is populated
without vNUMA information. Move the hunk to right place to fix this.
Move the subtraction of video ram to libxl__vnuma_build_vmemrange_hvm
% Partial `libxenctrl` API/ABI stabilisation
% Ian Campbell
% Draft A
# Introduction
The low-level `libxenctrl` library currently has an unstable API and
ABI and some of the hypervisor interfaces which it exposes are
similarly unstable.
However several external projects use some of these interf
>>> On 08.05.15 at 23:06, wrote:
> Code for initializing/tearing down PMU for PV guests
>
> Signed-off-by: Boris Ostrovsky
> Acked-by: Daniel De Graaf
Acked-by Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen
Hi Parth,
On 17/05/15 21:03, Parth Dixit wrote:
> From: Naresh Bhat
>
> When MADT is parsed, print GIC information to make the boot
> log look pretty.
>
> Signed-off-by: Hanjun Guo
> Signed-off-by: Tomasz Nowicki
> Signed-off-by: Naresh Bhat
> ---
> xen/drivers/acpi/tables.c | 39 ++
Hi Parth,
On 17/05/15 21:03, Parth Dixit wrote:
> With ACPI 5.0, we got per-processor timer support in GTDT,
> and ACPI 5.1 introduced the support for platform (memory-mapped)
> timers: GT Block and SBSA watchdog timer, add the code needed
> for the spec change.
>
> Signed-off-by: Hanjun Guo
> S
>>> On 08.05.15 at 23:06, wrote:
> --- /dev/null
> +++ b/xen/include/public/arch-x86/pmu.h
> @@ -0,0 +1,122 @@
> +#ifndef __XEN_PUBLIC_ARCH_X86_PMU_H__
> +#define __XEN_PUBLIC_ARCH_X86_PMU_H__
> +
> +/* x86-specific PMU definitions */
> +
> +/* AMD PMU registers and structures */
> +struct xen_pmu
On 05/18/2015 05:43 AM, Dietmar Hahn wrote:
Am Freitag 08 Mai 2015, 17:06:11 schrieb Boris Ostrovsky:
+if ( !is_hvm_vcpu(sampling) )
+{
+/* PV(H) guest */
+const struct cpu_user_regs *cur_regs;
+uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
+domid_
Hi Parth,
On 17/05/15 21:03, Parth Dixit wrote:
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> the former signals to the OS that the hardware is PSCI compliant.
> The latter selects the appropriate conduit for PSCI calls by
> toggling between Hypervisor Calls (HVC) and Secure
>>> On 15.05.15 at 18:08, wrote:
> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -32,20 +32,25 @@ static inline struct vcpu *mapcache_current_vcpu(void)
> return NULL;
>
> /*
> + * When using efi runtime page tables, we have the equivalent of the idle
[Adding George. In future, if you are interested in getting feedback on
a particular subsystem, look for it in the MAINTAINERS file, and Cc the
address(es) you find there]
On Mon, 2015-05-18 at 13:24 +0530, Rajendra Bele wrote:
> As per my knowledge.
> Credit scheduler sorts its queue of VCPUs wit
On 18/05/15 15:34, Boris Ostrovsky wrote:
> On 05/18/2015 10:09 AM, Andrew Cooper wrote:
>> On 18/05/15 15:00, Boris Ostrovsky wrote:
>>> On 05/18/2015 08:57 AM, Andrew Cooper wrote:
These changesets cause the respective libxc functions to
unconditonally
dereference their max_cpus/no
On 18/05/15 15:32, Jan Beulich wrote:
On 18.05.15 at 16:20, wrote:
>> Although, acpi_os_map_iomem is also part of the ACPI CA. Would a
>> function arch_acpi_os_map_memory suit for you?
>
> Only if we - other than Linux - really need this to be arch dependent.
The current implementation of a
On 05/18/2015 10:09 AM, Andrew Cooper wrote:
On 18/05/15 15:00, Boris Ostrovsky wrote:
On 05/18/2015 08:57 AM, Andrew Cooper wrote:
These changesets cause the respective libxc functions to unconditonally
dereference their max_cpus/nodes parameters as part of initial memory
allocations. It will
>>> On 18.05.15 at 16:20, wrote:
> Although, acpi_os_map_iomem is also part of the ACPI CA. Would a
> function arch_acpi_os_map_memory suit for you?
Only if we - other than Linux - really need this to be arch dependent.
Jan
___
Xen-devel mailing list
On Sun, Apr 19, 2015 at 11:50:48AM +0800, Chunyan Liu wrote:
> Sysfs file has size=4096 but actual file content is less than that.
> Current libxl_read_file_contents will treat it as error when file size
> and actual file content differs, so reading sysfs file content with
> this function always fa
Chunyan Liu writes ("[PATCH V3 2/6] libxl_read_file_contents: fix reading sysfs
file"):
> Sysfs file has size=4096 but actual file content is less than that.
Wow.
Is there any danger that the actual size might be >4096 ?
> Current libxl_read_file_contents will treat it as error when file size
On Mon, May 18, 2015 at 03:23:38PM +0100, Ian Jackson wrote:
> Chunyan Liu writes ("[PATCH V3 2/6] libxl_read_file_contents: fix reading
> sysfs file"):
> > Sysfs file has size=4096 but actual file content is less than that.
>
> Wow.
>
> Is there any danger that the actual size might be >4096 ?
Hi Parth,
On 17/05/15 21:03, Parth Dixit wrote:
> The Power State Coordination Interface (PSCI) defines an API that
> can be used to coordinate power control amongst the various supervisory
> systems concurrently running on a device. ACPI support for this
> technology would require the addition of
On Mon, 2015-05-18 at 15:23 +0100, Ian Jackson wrote:
> Perhaps the bulk should be made into libxl__read_file_contents_core
> which takes a boolean instructing whether to tolerate magically
> shrinking files ?
>
> Setting that boolean probably ought to arrange to insist that the
> function gets eo
All,
aiming at a release with presumably (i.e. as usual) one more RC,
please test!
Thanks, Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 18/05/15 15:01, Jan Beulich wrote:
On 18.05.15 at 15:26, wrote:
>> On 17/05/15 21:03, Parth Dixit wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/arm/acpi/lib.c
>>> @@ -0,0 +1,8 @@
>>> +#include
>>> +#include
>>> +
>>> +void __iomem *
>>> +acpi_os_map_iomem(acpi_physical_address phys, acpi_s
Hi Parth,
On 17/05/15 21:03, Parth Dixit wrote:
> acpi_boot_table_init() will be called in start_xen
> to get the RSDP and all the table pointers. with this patch,
> we can get ACPI boot-time tables from firmware on ARM64.
>
> Signed-off-by: Naresh Bhat
> Signed-off-by: Parth Dixit
> ---
> xen
On 18/05/15 15:00, Boris Ostrovsky wrote:
> On 05/18/2015 08:57 AM, Andrew Cooper wrote:
>> These changesets cause the respective libxc functions to unconditonally
>> dereference their max_cpus/nodes parameters as part of initial memory
>> allocations. It will fail at obtaining the correct number
On Sun, Apr 19, 2015 at 11:50:47AM +0800, Chunyan Liu wrote:
> Signed-off-by: Chunyan Liu
> Signed-off-by: Simon Cao
On the basis that this can help reduce the length of libxl.c and improve
maintainability by moving stuff out of libxl.c to dedicated files.
Acked-by: Wei Liu
> ---
> tools/lib
On 05/18/2015 08:57 AM, Andrew Cooper wrote:
These changesets cause the respective libxc functions to unconditonally
dereference their max_cpus/nodes parameters as part of initial memory
allocations. It will fail at obtaining the correct number of cpus/nodes from
Xen, as the guest handles will n
>>> On 18.05.15 at 15:26, wrote:
> On 17/05/15 21:03, Parth Dixit wrote:
>> --- /dev/null
>> +++ b/xen/arch/arm/acpi/lib.c
>> @@ -0,0 +1,8 @@
>> +#include
>> +#include
>> +
>> +void __iomem *
>> +acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
>> +{
>> +return __va(phys);
>> +}
Forgot to CC the Intel folks...
On 2015-5-18, at 15:55, Lars Eggert wrote:
>
> Hi,
>
> Roger asked me to send this bug report to xen-devel. I'm trying to bring up a
> Xen dom0 on a Fujitsu RX308, but it crashes when strying to start the kernel.
>
> Any ideas?
>
> Lars
>
>
Hi,
Roger asked me to send this bug report to xen-devel. I'm trying to bring up a
Xen dom0 on a Fujitsu RX308, but it crashes when strying to start the kernel.
Any ideas?
Lars
B2
__ _ _
On Sun, Apr 19, Chunyan Liu wrote:
> +static int libxl__usbctrl_add_xenstore(libxl__gc *gc, uint32_t domid,
> + libxl_device_usbctrl *usbctrl)
> +{
> +flexarray_append_pair(back, "state", "1");
> +flexarray_append_pair(front, "state", "1");
This (an
On Mon, 2015-05-18 at 14:33 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v4] OSSTEST: introduce a raisin
> build test"):
> > On Mon, 2015-05-18 at 14:05 +0100, George Dunlap wrote:
> > > That solves the most general case; but it sounds like you care mostly
> > > about t
>>> On 18.05.15 at 15:24, wrote:
> On 18/05/15 12:43, Jan Beulich wrote:
> On 18.05.15 at 12:59, wrote:
>>> +if ( unlikely(num > 1024) ||
>>> + unlikely(num != domctl->u.getpageframeinfo3.num) )
>>> +{
>>> +ret = -E2BIG;
>>> +break;
>>> +
>>> On 08.05.15 at 10:56, wrote:
> +int psr_get_l3_cbm(struct domain *d, unsigned int socket, uint64_t *cbm)
> +{
> +unsigned int cos;
> +struct psr_cat_socket_info *info;
> +int ret = get_cat_socket_info(socket, &info);
> +
> +if ( ret )
> +return ret;
> +
> +cos = d->
On 15/05/15 22:08, Julien Grall wrote:
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 c
>>> On 08.05.15 at 10:56, wrote:
> @@ -237,6 +243,14 @@ static void cat_cpu_init(void)
> info->cbm_len = (eax & 0x1f) + 1;
> info->cos_max = min(opt_cos_max, edx & 0x);
>
> +info->cos_to_cbm = xzalloc_array(struct psr_cat_cbm,
> +
Ian Campbell writes ("Re: [Xen-devel] [PATCH v4] OSSTEST: introduce a raisin
build test"):
> On Mon, 2015-05-18 at 14:05 +0100, George Dunlap wrote:
> > That solves the most general case; but it sounds like you care mostly
> > about the very specific case of dealing with components that depend on
On 04/20/2015 05:25 PM, Olaf Hering wrote:
> On Sun, Apr 19, Chunyan Liu wrote:
>
>> +++ b/tools/libxl/libxl_internal.h
>
>> +_hidden int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char
>> *device);
>> +_hidden int libxl__resolve_domid(libxl__gc *gc, const char *name,
>> +
>>> On 08.05.15 at 10:56, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -19,14 +19,26 @@
> #include
>
> #define PSR_CMT(1<<0)
> +#define PSR_CAT(1<<1)
> +
> +struct psr_cat_socket_info {
> +unsigned int cbm_len;
> +unsigned int cos_max;
> +};
>
>
On Mon, 2015-05-18 at 14:23 +0100, George Dunlap wrote:
> On 05/18/2015 02:14 PM, Ian Campbell wrote:
> >> That solves the most general case; but it sounds like you care mostly
> >> about the very specific case of dealing with components that depend on
> >> the current output of xen.git. Starting
On Wed, May 13, 2015 at 10:30 AM, Ian Campbell wrote:
> On Wed, 2015-05-13 at 10:54 +0200, Juergen Gross wrote:
>> Hi,
>>
>> while trying to build a pvusb backend in qemu I think I've found a
>> general issue in xl: qemu for pv-domains is started only at domain
>> creation and only if there is at
Hi Parth,
On 17/05/15 21:03, Parth Dixit wrote:
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 935999e..096e9ef 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -2,6 +2,7 @@ subdir-$(arm32) += arm32
> subdir-$(arm64) += arm64
> subdir-y += platforms
>
On 18/05/15 12:43, Jan Beulich wrote:
On 18.05.15 at 12:59, wrote:
>> In tree, there is one single caller of XEN_DOMCTL_getpageframeinfo3
>> (xc_get_pfn_type_batch()), and no callers of the older variants.
>>
>> getpageframeinfo3 and getpageframeinfo2 are compatible if the parameter
>> conten
On 05/18/2015 02:14 PM, Ian Campbell wrote:
>> That solves the most general case; but it sounds like you care mostly
>> about the very specific case of dealing with components that depend on
>> the current output of xen.git. Starting simple may be fine.
>
> Currently we only have ts-*-build thing
1 - 100 of 189 matches
Mail list logo
