On 9/29/2015 7:19 PM, Meng Xu wrote:
HI Andy,
2015-09-29 18:06 GMT-04:00 Andy Smith mailto:a...@strugglers.net>>:
Hi Tianyang,
On Mon, Sep 28, 2015 at 10:24:15PM -0400, soapcn wrote:
> I keep getting this error about not being able to get domain type
> when I try to create a do
This run is configured for baseline tests only.
flight 38094 xen-4.0-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38094/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
build-i386-libvirt1 build-check(
On Tue, 2015-09-29 at 17:21 +0100, Ian Jackson wrote:
> There are two patches here to fix annoyances which can make
> osstest-installed Debian guests hard to get into.
> And two patches to reorganise slightly the runvar handling:
> introducing a function `target_var' to replace `guest_var'. Curre
On Tue, 2015-09-29 at 17:33 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST v5] Add arm64 build and test
> jobs"):
> > Not quite, since the arm32 and arm64 h/w is distinct. These tests won't
> > run
> > on any of the arm32 hardware we have and the existing armhf tests won't
> >
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 patter for error handling, but I
> > can turn it into
On Tue, 2015-09-29 at 17:19 +0100, Anthony PERARD wrote:
> On Tue, Sep 29, 2015 at 04:34:44PM +0100, Ian Campbell wrote:
> > On Mon, 2015-09-28 at 16:56 +0100, Anthony PERARD wrote:
> > > This script installs any necessary packages and clones all of the
> > > OpenStack
> > > trees which are used by
On Mon, 2015-09-28 at 16:56 +0100, Anthony PERARD wrote:
> + # OpenStack needs access to libvirt from a user.
> + target_cmd_root($ho, < +cat >> /etc/libvirt/libvirtd.conf < +unix_sock_group = "libvirt"
> +unix_sock_ro_perms = "0777"
> +unix_sock_rw_perms = "0770"
> +EOF
> +END
One small nit
A previous version of this patch dealing with support for skipping
the current instruction when a vm_event response requested it
computed the instruction length in the hypervisor, adding non-trivial
code dependencies. This patch allows a userspace vm_event client to
simply request that the guest's
On Tue, 2015-09-29 at 18:15 +0100, Anthony PERARD wrote:
> On Tue, Sep 29, 2015 at 04:43:50PM +0100, Ian Campbell wrote:
> > On Mon, 2015-09-28 at 16:56 +0100, Anthony PERARD wrote:
> >
> > > + # Ignore these tests:
> > > + #
> > > tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.
On Wed, 2015-09-30 at 09:34 +0800, Chao Peng wrote:
> On Tue, Sep 29, 2015 at 10:55:40AM +0100, Ian Campbell wrote:
> > On Tue, 2015-09-29 at 10:27 +0100, Andrew Cooper wrote:
> > > On 29/09/15 08:49, Chao Peng wrote:
> > > > [1] Intel SDM
> > > > -(http://www.intel.com/content/www/us/en/processo
Good to me, if you have tested it. Sorry I cannot test it as I am
taking vacation until Oct.8.
Thanks,
-Kai
On Mon, Sep 28, 2015 at 10:42 PM, Jan Beulich wrote:
> There's no point in enabling the extra feature for every domain when
> we're not meaning to use it (yet). Just setting the flag shou
On 29/09/15 22:40, Dario Faggioli wrote:
> On Tue, 2015-09-29 at 18:31 +0100, Andrew Cooper wrote:
>> On 29/09/15 17:55, Dario Faggioli wrote:
>>> The insert_vcpu() scheduler hook is called with an
>>> inconsistent locking strategy. In fact, it is sometimes
>>> invoked while holding the runqueue lo
On 29/09/15 18:54, Wei Liu wrote:
> Please avoid top-posting.
>
> On Tue, Sep 29, 2015 at 01:43:29PM -0400, soapcn wrote:
>> Andrew,
>>
>> Yes, the domain is constructed and I can see it using xl list command. As
>> soon as I unpaused it, it crashed again.
>>
> You then need to figure out why it cr
On Wed, Sep 30, 2015 at 03:25:20PM +1000, Andrew Stuart wrote:
> As far as I can tell, Xen HVM domu guests detect and use the RTL8139
> network card thus its not a hard requirement to use the PVHVM drivers.
>
That's because the default emulated nic in libxl is RTL8139. You can
specify others as w
On 30/09/15 06:25, Andrew Stuart wrote:
> As far as I can tell, Xen HVM domu guests detect and use the RTL8139 network
> card thus its not a hard requirement to use the PVHVM drivers.
The rtl8139 (or e1000e, depending on configuration) are provided to HVM
guests to cater to a Xen unaware configur
> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Andrew Cooper
> Sent: 30 September 2015 10:11
> To: Andrew Stuart; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Xen / EC2 network HVM device visibility
>
> On 30/09/1
On Mon, Sep 28, 2015 at 10:09 PM, Jan Beulich wrote:
On 28.09.15 at 14:39, wrote:
>> --- a/xen/arch/x86/mm/p2m-ept.c
>> +++ b/xen/arch/x86/mm/p2m-ept.c
>> @@ -34,6 +34,8 @@
>>
>> #include "mm-locks.h"
>>
>> +static bool_t __read_mostly cpu_has_ept_ad;
>
> This should be
> #define cpu_has_ep
On Mon, Sep 28, 2015 at 01:39:34PM +0100, Ross Lagerwall 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 som
Hello xen-devel,
In context of my master's thesis I am performing an analysis of
hypervisor security vulnerabilities. Content of this analysis is, among
others, the relation of Patch Delivery Delay and various characteristics
of the identified vulnerabilities.
Patch delivery delay has been defin
> > Actually this is a suggestion from Lars during
> > he reviewing the documents for the 4.6 release. Because when one opens
> > the generic page he/she will see several options (combined volume set,
> > three-volume set and seven-volume set), it may be not easy to find out
> > the related chapte
On Wed, 2015-09-30 at 15:25 +1000, Andrew Stuart wrote:
This is not a question about the development of the Xen hypervisor.
Therefore I've moved xen-devel to bcc and added xen-users to the cc. Please
try and use the correct list in the future.
> As far as I can tell, Xen HVM domu guests detect an
>>> 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:
>> There's no point in enabling the extra feature for every doma
>>> On 30.09.15 at 02:02, wrote:
>
>> -Original Message-
>> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
>> boun...@lists.xen.org] On Behalf Of Jan Beulich
>> Sent: Tuesday, September 29, 2015 12:59 AM
>> To: xen-devel
>> Cc: George Dunlap; Andrew Cooper; Tian, Kevin; Keir Fr
>>> 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_base;
>>> uint32_t ss_base;
>>> uint32_t es_base
Hi Jan,
On 29/09/15 14:27, Jan Beulich wrote:
On 29.09.15 at 15:06, wrote:
>> On 29/09/15 14:00, Jan Beulich wrote:
>> On 29.09.15 at 14:52, wrote:
On 29/09/15 13:46, Jan Beulich wrote:
> Again, make map_mmio_regions() a wrapper around an ARM-specific
> function with the ex
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 30.09.15 at 12:22, 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 Tue, 2015-09-29 at 15:18 -0600, Mike Latimer wrote:
> Hi Ian,
>
> On Tuesday, September 29, 2015 10:25:32 AM Ian Campbell wrote:
> > On Mon, 2015-09-28 at 17:14 -0600, Mike Latimer wrote:
> > > Any better options or ideas?
> >
> > Is part of the problem that shell is a terrible choice for this
All the usage of the field pfn are done using the same idiom:
pfn_to_page(grant->pfn)
This will return always the same page. Store directly the page in the
grant to clean up the code.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszu
Prepare the code to support 64KB page granularity. The first
implementation will use a full Linux page per indirect and persistent
grant. When non-persistent grant is used, each page of a bio request
may be split in multiple grant.
Furthermore, the field page of the grant structure is only used to
The Xen hypercall interface is always using 4K page granularity on ARM
and x86 architecture.
With the incoming support of 64K page granularity for ARM64 guest, it
won't be possible to re-use the Linux page definition in Xen drivers.
Introduce Xen page definition helpers based on the Linux page
de
Hi all,
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 will result to a
guest crash.
This series is a first attempt to allow those
Many PV drivers contain the idiom:
pfn = page_to_gfn(...) /* Or similar */
gnttab_grant_foreign_access_ref
Replace it by a new helper. Note that when Linux is using a different
page granularity than Xen, the helper only gives access to the first 4KB
grant.
This is useful where drivers are alloca
Currently, a grant is always based on the Xen page granularity (i.e
4KB). When Linux is using a different page granularity, a single page
will be split between multiple grants.
The new helpers will be in charge of splitting the Linux page into grants
and call a function given by the caller on each
Currently, blkif_queue_request has 2 distinct execution path:
- Send a discard request
- Send a read/write request
The function is also allocating grants to use for generating the
request. Although, this is only used for read/write request.
Rather than having a function with 2 distinct ex
On ARM all dma-capable devices on a same platform may not be protected
by an IOMMU. The DMA requests have to use the BFN (i.e MFN on ARM) in
order to use correctly the device.
While the DOM0 memory is allocated in a 1:1 fashion (PFN == MFN), grant
mapping will screw this contiguous mapping.
When
They are not used in common code expect in one place in balloon.c which is
only compiled when Linux is using PV MMU. It's not the case on ARM.
Rather than worrying how to handle the 64KB case, drop them.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Russell King
Cha
The skb doesn't change within the function. Therefore it's only
necessary to check if we need GSO once at the beginning.
Signed-off-by: Julien Grall
Acked-by: Wei Liu
---
Cc: Ian Campbell
Cc: net...@vger.kernel.org
Changes in v4:
- Add Wei's acked
Changes in v2:
- Pat
On 30/09/15 11:45, Julien Grall wrote:
> Many PV drivers contain the idiom:
>
> pfn = page_to_gfn(...) /* Or similar */
> gnttab_grant_foreign_access_ref
>
> Replace it by a new helper. Note that when Linux is using a different
> page granularity than Xen, the helper only gives access to the firs
All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Changes in v3:
- Fix errors reported by checkpatch.pl
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity working as a
network backend on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on
The hypercall interface is always using 4KB page granularity. This is
requiring to use xen page definition macro when we deal with hypercall.
Note that pfn_to_gfn is working with a Xen pfn (i.e 4KB). We may want to
rename pfn_gfn to make this explicit.
We also allocate a 64KB page for the shared
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: David Vrabel
Cc: Boris Ostrovsky
Cc: linuxppc-...@lists.ozlabs.org
Changes in v4:
- The ring is always 4K (
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using network
device on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on the gran
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using block
device on a non-modified Xen.
The block API is using segment which should at least be the size of a
Linux page. Therefore, the driver will have to break the page
The Xen interface is using 4KB page granularity. This means that each
grant is 4KB.
The current implementation allocates a Linux page per grant. On Linux
using 64KB page granularity, only the first 4KB of the page will be
used.
We could decrease the memory wasted by sharing the page with multiple
Ian Campbell writes ("Re: [PATCH OSSTEST v3 1/3] ts-openstack-deploy: Deploy
OpenStack on a host with devstack"):
> On Mon, 2015-09-28 at 16:56 +0100, Anthony PERARD wrote:
> > + # OpenStack needs access to libvirt from a user.
> > + target_cmd_root($ho, < > +cat >> /etc/libvirt/libvirtd.con
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity behaving as a
block backend on a non-modified Xen.
It's only necessary to adapt the ring size and the number of request per
indirect frames. The rest of the code is relying o
Only use the first 4KB of the page to store the events channel info. It
means that we will waste 60KB every time we allocate page for:
* control block: a page is allocating per CPU
* event array: a page is allocating everytime we need to expand it
I think we can reduce the memory waste f
For ARM64 guests, Linux is able to support either 64K or 4K page
granularity. Although, the hypercall interface is always based on 4K
page granularity.
With 64K page granularity, a single page will be spread over multiple
Xen frame.
To avoid splitting the page into 4K frame, take advantage of the
The hypercall interface (as well as the toolstack) is always using 4KB
page granularity. When the toolstack is asking for mapping a series of
guest PFN in a batch, it expects to have the page map contiguously in
its virtual memory.
When Linux is using 64KB page granularity, the privcmd driver will
With 64KB page granularity support, the frame number will be different.
It will be easier to modify the behavior in a single place rather than
in each caller.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Russell King
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: D
On Wed, 2015-09-30 at 04:33 -0600, Jan Beulich wrote:
> > > > On 30.09.15 at 12:22, 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.
>
Swiotlb is used on ARM64 to support DMA on platform where devices are
not protected by an SMMU. Furthermore it's only enabled for DOM0.
While Xen is always using 4KB page granularity in the stage-2 page table,
Linux ARM64 may either use 4KB or 64KB. This means that a Linux page
can be spanned accr
The GICv3 driver read a 32 bit value for the re-distributor stride, but
the dts binding is a two-cell property.
All instances of rdist stride access and reference has been modified to
accommodate 64 bit value. The changes are compiled and verified on HiSilicon
Hip05 platform.
Signed-off-by: Shame
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 padding pages, specifies the stride
of consecuti
Hi Shameerali,
On 30/09/15 11:54, Shameerali Kolothum Thodi wrote:
> The GICv3 driver read a 32 bit value for the re-distributor stride, but
s/read/reads/
> the dts binding is a two-cell property.
I would mention that two-cell = 64 bit to make clear that the issue is
we are reading only one-ce
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
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 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 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 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
> -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 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
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
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 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
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 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
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 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 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 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 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 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
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 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
>>> 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 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 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
> > 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 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
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
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
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
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
> >> >> >>> 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
>>> 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
* 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 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
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 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
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 -
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 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()
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 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
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
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
1 - 100 of 157 matches
Mail list logo
