Hi,
On Mon, Sep 28, 2015 at 9:40 PM, Ian Campbell
wrote:
>
> I had a quick glance at coverity and found:
>
> CID1055958: use of mkstemp in libxl_vncviewer_exec without first setting a
> sensible umask.
>
> CID1311511: lack of error checking on the result of xc_dom_allocate in
init
> -xenstore-dom
flight 62526 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62526/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 30634ed870d6fdaa702c3e80e5ff2a0214106a49
baseline version:
ovmf 7a0ce8c572dff07cef82d7699da39ef52ad
>>> On 30.09.15 at 19:58, wrote:
> On 9/18/15 1:41 PM, Doug Goldstein wrote:
>> This variable appears to be unused throughout the code base.
>>
>> Signed-off-by: Doug Goldstein
>> ---
>> Makefile | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
On Thu, 2015-10-01 at 07:28 +0200, Juergen Gross wrote:
> On 09/29/2015 06:56 PM, Dario Faggioli wrote:
> > --- a/xen/common/schedule.c
> > +++ b/xen/common/schedule.c
> > @@ -1501,8 +1501,8 @@ int schedule_cpu_switch(unsigned int cpu,
> > struct cpupool *c)
> > return 0;
> >
> >
On Thu, 2015-10-01 at 07:21 +0200, Juergen Gross wrote:
> On 09/29/2015 06:55 PM, Dario Faggioli wrote:
> > --- a/xen/common/schedule.c
> > +++ b/xen/common/schedule.c
> > @@ -1407,6 +1407,9 @@ static int cpu_schedule_callback(
> >
> > switch ( action )
> > {
> > +case CPU_STARTIN
On 09/29/2015 06:56 PM, Dario Faggioli wrote:
Experiments have shown that arranging the scheduing
runqueues on a per-core basis yields better results,
in most cases.
Such evaluation has been done, for the first time,
by Uma Sharma, during her participation to OPW. Some
of the results she got are
On 09/29/2015 06:56 PM, Dario Faggioli wrote:
In fact, credit2 uses CPU topology to decide how to arrange
its internal runqueues. Before this change, only 'one runqueue
per socket' was allowed. However, experiments have shown that,
for instance, having one runqueue per physical core improves
perf
On 09/29/2015 06:56 PM, Dario Faggioli wrote:
The .alloc_pdata hook of the scheduler interface is
called, in schedule_cpu_switch(), unconditionally,
for all schedulers.
This forces even schedulers that do not require any
actual allocation of per-pCPU data to:
- contain an implementation of the
On 09/29/2015 06:55 PM, Dario Faggioli wrote:
From: Uma Sharma
Signed-off-by: Uma Sharma
Signed-off-by: Dario Faggioli
Reviewed-by: Juergen Gross
---
Cc: George Dunlap
---
xen/common/sched_credit2.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/co
On 09/29/2015 06:55 PM, Dario Faggioli wrote:
Signed-off-by: Dario Faggioli
Reviewed-by: Juergen Gross
---
Cc: George Dunlap
---
xen/common/sched_credit2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
inde
On 09/29/2015 06:55 PM, Dario Faggioli wrote:
with the purpose of decoupling the allocation phase and
the initialization one, for per-pCPU data of the schedulers.
This makes it possible to perform the initialization later
in the pCPU bringup/assignement process, when more information
(for instan
flight 62520 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62520/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qcow2 13 guest-saverestore fail REGR. vs. 60666
test-amd64-i386-xl-vhd
flight 38109 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38109/
Perfect :-)
All tests in this flight passed
baseline version:
flight 38023
jobs:
build-amd64 pass
build-armhf
flight 62500 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62500/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail in 62416 pass
in 62500
test-amd64-amd64-rumpuse
flight 62491 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62491/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-vhd9 debian-di-install fail REGR. vs. 60565
test-am
flight 38096 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38096/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-current-netinst-pygrub 3 host-install(3) broken REGR.
vs. 3800
flight 62486 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62486/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 60670
test-amd64-amd64-xl-qc
Create the list of shared loopback devices from within check_sharing, rather
than calling check_sharing for every loopback device using the same shared
image.
This change prevents the xenstore database from being walked for every shared
device, which causes an exponential decrease in performance.
As mentioned in a previous thread[1], the hotplug block script suffers
from an exponential performance degredation when attaching shared image
files due to scanning xenstore multiple times.
During the attachment of a loopback mounted image file, the mode of all
curent instances of this device alre
This run is configured for baseline tests only.
flight 38095 qemu-upstream-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38095/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 5 li
This run is configured for baseline tests only.
flight 38097 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38097/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 7a0ce8c572dff07cef82d7699da39ef52adbf523
baseline version:
ovm
On 09/21/2015 09:36 AM, Linus Torvalds wrote:
>
> How many msr reads are so critical that the function call
> overhead would matter? Get rid of the inline version of the _safe()
> thing too, and put that thing there too.
>
Probably only the ones that may go in the context switch path.
-
flight 62572 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62572/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
On 29/09/15 15:23, Ian Campbell wrote:
> On Tue, 2015-09-29 at 14:36 +0100, Julien Grall wrote:
>> On 29/09/15 14:07, Ian Campbell wrote:
>>> On Fri, 2015-09-25 at 15:51 +0100, Julien Grall wrote:
Xen is currently directly storing the value of register
GICD_ITARGETSR
(for GICv2) and
On Wed, Sep 30, 2015 at 7:01 AM, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
>> On Mon, Sep 21, 2015 at 09:36:15AM -0700, Linus Torvalds wrote:
>> > On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
>> > >
>> > > Linus, what's your preference?
>> >
>> > So quite frankly, is there any reas
On 30/09/15 18:58, Doug Goldstein wrote:
> On 9/18/15 1:41 PM, Doug Goldstein wrote:
>> This variable appears to be unused throughout the code base.
>>
>> Signed-off-by: Doug Goldstein
>> ---
>> Makefile | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/Makefile b/Make
On 9/18/15 1:41 PM, Doug Goldstein wrote:
> This variable appears to be unused throughout the code base.
>
> Signed-off-by: Doug Goldstein
> ---
> Makefile | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 75177f0..8a9331f 100644
> --- a/Make
On 25/09/15 03:11, Chunyan Liu wrote:
> Add pvusb APIs, including:
> - attach/detach (create/destroy) virtual usb controller.
> - attach/detach usb device
> - list usb controllers and usb devices
> - get information of usb controller and usb device
> - some other helper functions
>
> Signed-o
On Wed, 2015-09-30 at 17:29 +0200, Olaf Hering wrote:
> On Wed, Sep 30, Wei Liu wrote:
>
> > Change "socket" to "socketid" to fix the problem.
>
> Tested-by: Olaf Hering
acked + applied to staging and staging-4.6.
___
Xen-devel mailing list
Xen-deve
Hi Fu,
I backported your patches to the CentOS aarch64 grub2 rpm. I am testing
it on X-Gene with EFI firmware. It works fine when booting Xen, but
booting native kernels (no Xen) doesn't work anymore. Grub prints
error: out of memory.
Press any key to continue...
grub is still able to continue
Try to use "xen-qemudepriv-domid$domid" first, then
"xen-qemudepriv-shared" and root if everything else fails.
The uids need to be manually created by the user or, more likely, by the
xen package maintainer.
Expose a device_model_user setting in libxl_domain_build_info, so that
opinionated caller
On 09/30/2015 06:39 PM, Jan Beulich wrote:
On 30.09.15 at 17:27, wrote:
>> On 09/30/2015 06:23 PM, Jan Beulich wrote:
>> On 30.09.15 at 17:16, wrote:
VM_EVENT_FLAG_SET_REGISTERS and xc_monitor_emulate_each_rep() are
not available in Xen 4.6, hence the bump.
>>>
>>> I don't foll
flight 62564 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62564/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
On Wed, 30 Sep 2015, Ian Campbell wrote:
> On Tue, 2015-09-29 at 18:07 +0100, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [PATCH v7] run QEMU as non-root"):
> > > On Fri, 7 Aug 2015, Wei Liu wrote:
> > > > Please use for / while to loop.
> > >
> > > The goto retry loop is a very common p
>>> On 30.09.15 at 16:23, wrote:
> On 30/09/15 13:12, Jan Beulich wrote:
> On 29.09.15 at 18:45, wrote:
>>> On Mon, Sep 28, 2015 at 3:30 PM, Jan Beulich wrote:
Now that p2m->get_entry() always returns a valid order, utilize this
to accelerate some of the operations in PoD code. (Th
>>> On 30.09.15 at 16:23, wrote:
> El 30/09/15 a les 14.35, Jan Beulich ha escrit:
>> On 30.09.15 at 14:19, wrote:
>>> For VCPU_HVM_MODE_32B:
>>> - rIP within CS limit.
>>> - Check that CS.DPL == SS.DPL.
>>> - rSP within SS limit.
>>>
>>> TBH I don't think we should enforce the last two checks
>>> On 30.09.15 at 17:27, wrote:
> On 09/30/2015 06:23 PM, Jan Beulich wrote:
> On 30.09.15 at 17:16, wrote:
>>> VM_EVENT_FLAG_SET_REGISTERS and xc_monitor_emulate_each_rep() are
>>> not available in Xen 4.6, hence the bump.
>>
>> I don't follow: These are additions, not changes that require
On 09/30/2015 06:34 PM, Jan Beulich wrote:
On 30.09.15 at 17:28, wrote:
>> On 09/30/2015 06:25 PM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 30/09/15 16:16, Razvan Cojocaru wrote:
VM_EVENT_FLAG_SET_REGISTERS and xc_monitor_emulate_each_rep() are
not available in Xen 4.6, hence the bump
>>> On 30.09.15 at 17:28, wrote:
> On 09/30/2015 06:25 PM, Julien Grall wrote:
>> Hi,
>>
>> On 30/09/15 16:16, Razvan Cojocaru wrote:
>>> VM_EVENT_FLAG_SET_REGISTERS and xc_monitor_emulate_each_rep() are
>>> not available in Xen 4.6, hence the bump.
>>
>> Shouldn't you bump XEN_DOMCTL_INTERFACE_
On Wed, Sep 30, Wei Liu wrote:
> Change "socket" to "socketid" to fix the problem.
Tested-by: Olaf Hering
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
El 30/09/15 a les 14.50, Andrew Cooper ha escrit:
> On 30/09/15 13:35, Jan Beulich wrote:
> On 30.09.15 at 14:19, wrote:
>>> El 30/09/15 a les 13.54, Jan Beulich ha escrit:
>>> On 30.09.15 at 13:37, wrote:
> /*
> * Using VCPU_HVM_MODE_64B implies that the vCPU is launched
On 09/30/2015 06:25 PM, Julien Grall wrote:
> Hi,
>
> On 30/09/15 16:16, Razvan Cojocaru wrote:
>> VM_EVENT_FLAG_SET_REGISTERS and xc_monitor_emulate_each_rep() are
>> not available in Xen 4.6, hence the bump.
>
> Shouldn't you bump XEN_DOMCTL_INTERFACE_VERSION and
> VM_EVENT_INTERFACE_VERSION in
On Wed, 2015-09-30 at 16:11 +0100, Ian Jackson wrote:
> Ian Jackson writes ("[OSSTEST PATCH] Executive HTML output: Use #88
> (grey) for queued jobs"):
> > Either the flight hasn't started yet, or the job is blocked waiting
> > for other jobs to finish. In any case their state is not very
> >
Hi,
On 30/09/15 16:16, Razvan Cojocaru wrote:
> VM_EVENT_FLAG_SET_REGISTERS and xc_monitor_emulate_each_rep() are
> not available in Xen 4.6, hence the bump.
Shouldn't you bump XEN_DOMCTL_INTERFACE_VERSION and
VM_EVENT_INTERFACE_VERSION instead?
The former for xc_monitor_emulate_each_read as it'
On 09/30/2015 06:23 PM, Jan Beulich wrote:
On 30.09.15 at 17:16, wrote:
>> VM_EVENT_FLAG_SET_REGISTERS and xc_monitor_emulate_each_rep() are
>> not available in Xen 4.6, hence the bump.
>
> I don't follow: These are additions, not changes that require
> consumers to adapt their code.
I have
>>> On 30.09.15 at 17:16, wrote:
> VM_EVENT_FLAG_SET_REGISTERS and xc_monitor_emulate_each_rep() are
> not available in Xen 4.6, hence the bump.
I don't follow: These are additions, not changes that require
consumers to adapt their code.
Jan
___
Xen-
VM_EVENT_FLAG_SET_REGISTERS and xc_monitor_emulate_each_rep() are
not available in Xen 4.6, hence the bump.
Signed-off-by: Razvan Cojocaru
---
xen/include/public/xen-compat.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/public/xen-compat.h b/xen/include/publ
On Tue, Sep 29, 2015 at 11:01:44AM +0100, Lars Kurth wrote:
> Hi,
>
> I agree to the conditions in the XenProject Coverity contribution
> guidelines [1].
>
> I have been community manager for the Xen Project since 2011 and
> chairman of the Xen Project Advisory Board since 2013.
>
> I would lik
On Mon, Sep 28, 2015 at 10:53:33PM +0200, Christoffer Dall wrote:
> On Mon, Sep 14, 2015 at 5:20 PM, Ian Campbell
> wrote:
>
> > On Mon, 2015-09-14 at 14:40 +0200, Christoffer Dall wrote:
> > > On Fri, Jul 31, 2015 at 03:17:56PM +0200, Christoffer Dall wrote:
> > > > On Fri, Jul 31, 2015 at 12:28
Ian Jackson writes ("[OSSTEST PATCH] Executive HTML output: Use #88 (grey)
for queued jobs"):
> Either the flight hasn't started yet, or the job is blocked waiting
> for other jobs to finish. In any case their state is not very
> interesting.
>
> Most usefully this change visually distinguis
>> >>> On September 29, 2015, at 5:12 PM, wrote:
> At 03:08 + on 28 Sep (1443409723), Xu, Quan wrote:
> > >>> Thursday, September 24, 2015 12:27 AM, Tim Deegan wrote:
> > > 7/13: I'm not convinced that making the vcpu spin calling
> > > sched_yield() is a very good plan. Better to explicitly
Either the flight hasn't started yet, or the job is blocked waiting
for other jobs to finish. In any case their state is not very
interesting.
Most usefully this change visually distinguishes, in the plan summary,
jobs which are waiting for prior jobs to finish, from ones which have
entered the p
Roger Pau Monné writes ("Re: [PATCH OSSTEST 4/6] ts-freebsd-install: Use
$gho->{Lvdev} instead of target_guest_lv_name"):
> El 29/09/15 a les 11.44, Ian Campbell ha escrit:
> > prepareguest has already assigned this so we should use it instead of
> > replicating (perhaps wrongly since target_guest
flight 62485 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62485/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 62295
test-armhf-armhf-xl-xs
On Wed, Sep 30, 2015 at 05:02:32PM +0200, Olaf Hering wrote:
> On Wed, Sep 30, Wei Liu wrote:
>
> > On Wed, Sep 30, 2015 at 03:46:35PM +0200, Olaf Hering wrote:
> > > [ 1227s] libxl_psr.c:342: error: declaration of 'socket' shadows a global
> > > declaration
> > I will provide a patch to fix it.
On Wed, Sep 30, Wei Liu wrote:
> On Wed, Sep 30, 2015 at 03:46:35PM +0200, Olaf Hering wrote:
> > [ 1227s] libxl_psr.c:342: error: declaration of 'socket' shadows a global
> > declaration
> I will provide a patch to fix it.
Thanks. Staging is broken as well as I noticed just now.
Olaf
SLES11 and OpenSUSE 11.4 complain:
[ 1227s] libxl_psr.c: In function 'libxl_psr_cat_get_l3_info':
[ 1227s] libxl_psr.c:342: error: declaration of 'socket' shadows a > global
declaration
Change "socket" to "socketid" to fix the problem.
Reported-by: Olaf Hering
Signed-off-by: Wei Liu
Cc: Chao
El 29/09/15 a les 11.44, Ian Campbell ha escrit:
> prepareguest has already assigned this so we should use it instead of
> replicating (perhaps wrongly since target_guest_lv_name and
> target_choose_vg can behave differently if multiple vgs are present).
>
> Signed-off-by: Ian Campbell
> Cc: Roge
This run is configured for baseline tests only.
flight 38093 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38093/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 9 window
On Wed, 2015-09-30 at 15:04 +0100, Ian Jackson wrote:
> We don't need to test every combination of toolstack, architecture,
> and disk format. We don't expect many architecture-specific bugs in
> the per-disk-format code in the toolstack layers.
>
> We _do_ want to test every combination of tools
On Tue, 2015-09-29 at 10:44 +0100, Ian Campbell wrote:
> * A firmware upgrade on the Arndale boards, since the new version of gcc
>seems to trigger an SoC errata when building the kernel.
Now done.
> The reason I care about upgrading to Jessie is that this adds the arm64
> architecture whic
On 30/09/15 13:12, Jan Beulich wrote:
On 29.09.15 at 18:45, wrote:
>> On Mon, Sep 28, 2015 at 3:30 PM, Jan Beulich wrote:
>>> Now that p2m->get_entry() always returns a valid order, utilize this
>>> to accelerate some of the operations in PoD code. (There are two uses
>>> of p2m->get_entry()
El 30/09/15 a les 14.35, Jan Beulich ha escrit:
> On 30.09.15 at 14:19, wrote:
>> For VCPU_HVM_MODE_32B:
>> - rIP within CS limit.
>> - Check that CS.DPL == SS.DPL.
>> - rSP within SS limit.
>>
>> TBH I don't think we should enforce the last two checks, starting with
>> an invalid stack should
On Wed, Sep 30, 2015 at 03:46:35PM +0200, Olaf Hering wrote:
> Current xen-4.6-staging fails to compile on openSUSE 11.4 and SLES11
>
> [ 1227s] gcc -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99
> -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__
> -MMD -
>>> On 30.09.15 at 15:55, wrote:
>> >> >> >>> On September 29, 2015 at 3:22 PM, wrote:
>> >>> On 29.09.15 at 04:53, wrote:
>> Monday, September 28, 2015 2:47 PM, wrote:
>> >> >>> On 28.09.15 at 05:08, wrote:
>> >> Thursday, September 24, 2015 12:27 AM, Tim Deegan wrote:
>> >
>> > For
We don't need to test every combination of toolstack, architecture,
and disk format. We don't expect many architecture-specific bugs in
the per-disk-format code in the toolstack layers.
We _do_ want to test every combination of toolstack and disk format
(since the format configuration machinery i
On Wed, 2015-09-30 at 15:49 +0200, Fabio Fantoni wrote:
> I still not found a good and "all-in-one" solution but I saw this open
> source project: patchwork http://jk.ozlabs.org/projects/patchwork/
> Seems interesting, is integrated with mailing list, now seems with
> "basic features" but probably
* Peter Zijlstra wrote:
> On Mon, Sep 21, 2015 at 09:36:15AM -0700, Linus Torvalds wrote:
> > On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
> > >
> > > Linus, what's your preference?
> >
> > So quite frankly, is there any reason we don't just implement
> > native_read_msr() as just
> >
>>> On 30.09.15 at 15:36, wrote:
> The 3 options which (sub)arches have for the layout of their heaps is
> a little subtle (in particular the two CONFIG_SEPARATE_XENHEAP=n
> submodes) and can be a bit tricky to derive from the code.
>
> Therefore try and write down some guidance on what the vario
> >> >> >>> On September 29, 2015 at 3:22 PM, wrote:
> >>> On 29.09.15 at 04:53, wrote:
> Monday, September 28, 2015 2:47 PM, wrote:
> >> >>> On 28.09.15 at 05:08, wrote:
> >> Thursday, September 24, 2015 12:27 AM, Tim Deegan wrote:
> >
> > For Tim's suggestion --"to make the IOMMU tab
Il 31/08/2015 21:38, Russell Pavlicek ha scritto:
Please forgive the top-post. I am stuck with an interface which does not
facilitate inline replies (as insane as that may sound).
Russell has evaluated some off-the shelf tooling that would allow bridging
the gap: unfortunately there is nothin
Current xen-4.6-staging fails to compile on openSUSE 11.4 and SLES11
[ 1227s] gcc -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99
-Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD
-MF .libxl_psr.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-fmessage
The 3 options which (sub)arches have for the layout of their heaps is
a little subtle (in particular the two CONFIG_SEPARATE_XENHEAP=n
submodes) and can be a bit tricky to derive from the code.
Therefore try and write down some guidance on what the various modes
are.
Note that this is intended mo
On Wed, 2015-09-30 at 11:29 +, Shameerali Kolothum Thodi wrote:
>
> > -Original Message-
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: 30 September 2015 12:04
> > To: Shameerali Kolothum Thodi; xen-de...@lists.xenproject.org
> > Cc: julien.gr...@citrix.com; vijaya.k
On Mon, Sep 21, 2015 at 09:36:15AM -0700, Linus Torvalds wrote:
> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
> >
> > Linus, what's your preference?
>
> So quite frankly, is there any reason we don't just implement
> native_read_msr() as just
>
>unsigned long long native_read_msr(uns
> > Just to check, would this be expected to work with a 16K DomU (e.g.
> > [2])?
> >
> > From a quick scan it looks like the relaxations provided by this series
> > should work so long as PAGE_SIZE % XEN_PAGE_SIZE == 0, assuming I
> > haven't missed something.
>
> Correct, this series is able to
On 30/09/15 13:35, Jan Beulich wrote:
On 30.09.15 at 14:19, wrote:
>> El 30/09/15 a les 13.54, Jan Beulich ha escrit:
>> On 30.09.15 at 13:37, wrote:
/*
* Using VCPU_HVM_MODE_64B implies that the vCPU is launched
* directly in long mode, so the type of the ca
On Wed, Sep 30, 2015 at 5:54 PM, Jan Beulich wrote:
On 30.09.15 at 10:58, wrote:
>> Good to me, if you have tested it. Sorry I cannot test it as I am
>> taking vacation until Oct.8.
>
> Note how I asked for help with testing ...
>
>> On Mon, Sep 28, 2015 at 10:42 PM, Jan Beulich wrote:
>>>
>>> On 30.09.15 at 14:19, wrote:
> El 30/09/15 a les 13.54, Jan Beulich ha escrit:
> On 30.09.15 at 13:37, wrote:
>>> /*
>>> * Using VCPU_HVM_MODE_64B implies that the vCPU is launched
>>> * directly in long mode, so the type of the cached part
>>> * of the TR register is s
On Wed, Sep 30, 2015 at 05:36:22AM -0600, Jan Beulich wrote:
> Since commit 191b3f3344ee ("p2m/ept: enable PML in p2m-ept for
> log-dirty"), the A and D bits of EPT paging entries are set
> unconditionally, regardless of whether PML is enabled or not. This
> causes a regression in Xen 4.6 on some p
El 30/09/15 a les 13.54, Jan Beulich ha escrit:
On 30.09.15 at 13:37, wrote:
>> This is what I currently have prototyped according to the comments, it
>> should allow starting the vCPU in all possible modes AFAICT.
>
> Looks okay, one more comment:
>
>> struct vcpu_hvm_x86_32 {
>> uint
>>> On 29.09.15 at 18:45, wrote:
> On Mon, Sep 28, 2015 at 3:30 PM, Jan Beulich wrote:
>> Now that p2m->get_entry() always returns a valid order, utilize this
>> to accelerate some of the operations in PoD code. (There are two uses
>> of p2m->get_entry() left which don't easily lend themselves to
On 30/09/15 13:02, Jan Beulich wrote:
On 30.09.15 at 13:47, wrote:
>> On 30/09/15 12:36, Jan Beulich wrote:
>>> Since commit 191b3f3344ee ("p2m/ept: enable PML in p2m-ept for
>>> log-dirty"), the A and D bits of EPT paging entries are set
>>> unconditionally, regardless of whether PML is enab
>>> On 30.09.15 at 13:47, wrote:
> On 30/09/15 12:36, Jan Beulich wrote:
>> Since commit 191b3f3344ee ("p2m/ept: enable PML in p2m-ept for
>> log-dirty"), the A and D bits of EPT paging entries are set
>> unconditionally, regardless of whether PML is enabled or not. This
>> causes a regression in
>>> On 30.09.15 at 13:37, wrote:
> This is what I currently have prototyped according to the comments, it
> should allow starting the vCPU in all possible modes AFAICT.
Looks okay, one more comment:
> struct vcpu_hvm_x86_32 {
> uint32_t eax;
> uint32_t ecx;
> uint32_t edx;
> uin
On 30/09/15 12:37, Roger Pau Monné wrote:
> El 30/09/15 a les 12.03, Jan Beulich ha escrit:
> On 29.09.15 at 18:49, wrote:
>>> El 29/09/15 a les 18.20, Jan Beulich ha escrit:
>>> On 29.09.15 at 18:01, wrote:
> Yes, I should add back all the registers here, so it looks like:
>
On 30/09/15 12:32, Mark Rutland wrote:
> On Wed, Sep 30, 2015 at 11:45:15AM +0100, Julien Grall wrote:
>> Hi all,
>
> Hi,
>
>> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
>> hypercall interface and PV protocol are always based on 4KB page granularity.
>>
>> Any att
On 30/09/15 12:36, Jan Beulich wrote:
> Since commit 191b3f3344ee ("p2m/ept: enable PML in p2m-ept for
> log-dirty"), the A and D bits of EPT paging entries are set
> unconditionally, regardless of whether PML is enabled or not. This
> causes a regression in Xen 4.6 on some processors due to Intel
>>> On 30.09.15 at 13:31, wrote:
> On Wed, 2015-09-30 at 12:10 +0100, Andrew Cooper wrote:
>
>> > + *
>> > + * Xen heap pages are always anonymous (that is, not tied
>> > + * or accounted to any particular domain).
>> > + *
>> > + * - Dom heap: Memory which must be explici
El 30/09/15 a les 12.03, Jan Beulich ha escrit:
On 29.09.15 at 18:49, wrote:
>> El 29/09/15 a les 18.20, Jan Beulich ha escrit:
>> On 29.09.15 at 18:01, wrote:
Yes, I should add back all the registers here, so it looks like:
uint32_t cs_base;
uint32_t ds_bas
On 30/09/15 12:31, Ian Campbell wrote:
> On Wed, 2015-09-30 at 12:10 +0100, Andrew Cooper wrote:
>
>>> + *
>>> + * Xen heap pages are always anonymous (that is, not tied
>>> + * or accounted to any particular domain).
>>> + *
>>> + * - Dom heap: Memory which must be explicit
Since commit 191b3f3344ee ("p2m/ept: enable PML in p2m-ept for
log-dirty"), the A and D bits of EPT paging entries are set
unconditionally, regardless of whether PML is enabled or not. This
causes a regression in Xen 4.6 on some processors due to Intel Errata
AVR41 -- HVM guests get severe memory c
On Wed, Sep 30, 2015 at 11:45:15AM +0100, Julien Grall wrote:
> Hi all,
Hi,
> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
> hypercall interface and PV protocol are always based on 4KB page granularity.
>
> Any attempt to boot a Linux guest with 64KB pages enabled
On Wed, 2015-09-30 at 12:10 +0100, Andrew Cooper wrote:
> > + *
> > + * Xen heap pages are always anonymous (that is, not tied
> > + * or accounted to any particular domain).
> > + *
> > + * - Dom heap: Memory which must be explicitly mapped, usually
> > + * tra
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 30 September 2015 12:04
> To: Shameerali Kolothum Thodi; xen-de...@lists.xenproject.org
> Cc: julien.gr...@citrix.com; vijaya.ku...@caviumnetworks.com
> Subject: Re: [PATCH] xen/arm: Correctly read the GICv
On 30/09/15 12:28, Ian Campbell wrote:
> On Wed, 2015-09-30 at 12:10 +0100, Andrew Cooper wrote:
>> + *
>>> + * CONFIG_SEPARATE_XENHEAP=n W/ ONLY DIRECT MAP OF ONLY PARTIAL RAM
>>> + *
>>> + * There is a single heap, but only the beginning (up to some
>>> + * threshold) is covered by a permanen
On Wed, 2015-09-30 at 12:10 +0100, Andrew Cooper wrote:
> + *
> > + * CONFIG_SEPARATE_XENHEAP=n W/ ONLY DIRECT MAP OF ONLY PARTIAL RAM
> > + *
> > + * There is a single heap, but only the beginning (up to some
> > + * threshold) is covered by a permanent contiguous mapping.
>
> Perhaps avoid t
On 25/09/15 03:11, 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 fails.
>
> Add a new ent
On 30/09/15 12:04, Ian Campbell wrote:
> On Wed, 2015-09-30 at 11:54 +0100, Shameerali Kolothum Thodi wrote:
>> The GICv3 driver read a 32 bit value for the re-distributor stride, but
>> the dts binding is a two-cell property.
>
> The binding doc I have says:
>
> - redistributor-stride : If using
On 30/09/15 11:22, Ian Campbell wrote:
> The 3 options which (sub)arches have for the layout of their heaps is
> a little subtle (in particular the two CONFIG_SEPARATE_XENHEAP=n
> submodes) and can be a bit tricky to derive from the code.
>
> Therefore try and write down some guidance on what the v
1 - 100 of 157 matches
Mail list logo
