[Xen-devel] [xen-unstable-smoke test] 62572: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH] build: drop unused SUBARCH variable

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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.

Re: [Xen-devel] [PATCH] build: drop unused SUBARCH variable

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

Re: [Xen-devel] [PATCH OSSTEST v5] Add arm64 build and test jobs

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 >

Re: [Xen-devel] [PATCH OSSTEST v3 1/3] ts-openstack-deploy: Deploy OpenStack on a host with devstack

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

[Xen-devel] [distros-debian-sid test] 38092: tolerable FAIL

flight 38092 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38092/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-amd64-sid-netboot-pygrub 13 guest-saverestore fail blocked in 37972

Re: [Xen-devel] [OSSTEST PATCH 0/4] Miscellaneous bald yaks

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'.

Re: [Xen-devel] [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.conf < +unix_sock_group = "libvirt" > +unix_sock_ro_perms = "0777" > +unix_sock_rw_perms = "0770" > +EOF > +END One

Re: [Xen-devel] [PATCH OSSTEST v3 2/3] ts-openstack-tempest: Run Tempest to check OpenStack

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: > > > + # > > >

Re: [Xen-devel] Xen4.7 unable to get domain type for domid

On 9/29/2015 7:19 PM, Meng Xu wrote: HI Andy, 2015-09-29 18:06 GMT-04:00 Andy Smith >: 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 >

[Xen-devel] [PATCH V4] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS

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

Re: [Xen-devel] [PATCH v7] run QEMU as non-root

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

[Xen-devel] [xen-4.0-testing baseline-only test] 38094: tolerable FAIL

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

[Xen-devel] [linux-3.10 test] 62486: regressions - FAIL

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

[Xen-devel] [ovmf baseline-only test] 38097: all pass

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:

[Xen-devel] [qemu-upstream-4.5-testing baseline-only test] 38095: regressions - FAIL

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

[Xen-devel] [PATCH 1/1] tools/hotplug: Scan xenstore once when attaching shared images files

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.

Re: [Xen-devel] [PATCH v2 for Xen 4.6 5/6] docs: make xl-psr.markdown more precise

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 > > > >

Re: [Xen-devel] Xen4.7 unable to get domain type for domid

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

Re: [Xen-devel] [PATCHv2 for-4.6] p2m/ept: Work around hardware errata setting A bit

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

Re: [Xen-devel] [PATCH v6 24/29] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs

>>> 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; >>>

Re: [Xen-devel] [PATCH] xen/arm: Correctly read the GICv3 Re-Distributor stride

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

Re: [Xen-devel] [PATCH v6 24/29] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs

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

Re: [Xen-devel] [PATCH 3/9] xen: sched: make locking for {insert, remove}_vcpu consistent

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

Re: [Xen-devel] Xen / EC2 network HVM device visibility

> -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

[Xen-devel] [PATCH DOCDAY] xen: write a high level description of the sub-arch choices for heap layout

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

Re: [Xen-devel] [PATCH DOCDAY] xen: write a high level description of the sub-arch choices for heap layout

>>> 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

Re: [Xen-devel] [PATCH] xen/arm: Correctly read the GICv3 Re-Distributor stride

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

Re: [Xen-devel] [PATCH DOCDAY] xen: write a high level description of the sub-arch choices for heap layout

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

Re: [Xen-devel] [PATCH DOCDAY] xen: write a high level description of the sub-arch choices for heap layout

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 > > + *

Re: [Xen-devel] Xen / EC2 network HVM device visibility

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

Re: [Xen-devel] [PATCH] x86/EPT: defer enabling of A/D maintenance until PML get enabled

>>> 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

Re: [Xen-devel] Shared image files and block script performance

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

[Xen-devel] [PATCH] xen/arm: Correctly read the GICv3 Re-Distributor stride

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:

Re: [Xen-devel] [PATCH] xen/arm: Correctly read the GICv3 Re-Distributor stride

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

[Xen-devel] [Research] Correlation of Patch Delivery Delay and Access Complexity

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

Re: [Xen-devel] [PATCHv2 for-4.6] p2m/ept: Work around hardware errata setting A bit

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

Re: [Xen-devel] [PATCH 3/4 RFC] x86/p2m: use large pages for MMIO mappings

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

[Xen-devel] [PATCH v5 16/22] block/xen-blkback: Make it running on 64KB page granularity

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

[Xen-devel] [PATCH v5 13/22] xen/events: fifo: Make it running on 64KB granularity

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

[Xen-devel] [PATCH v5 12/22] xen/balloon: Don't rely on the page granularity is the same for Xen and Linux

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

[Xen-devel] [PATCH v5 19/22] xen/privcmd: Add support for Linux 64KB page granularity

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

[Xen-devel] [PATCH v5 21/22] xen/swiotlb: Pass addresses rather than frame numbers to xen_arch_need_swiotlb

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

[Xen-devel] [PATCH v5 20/22] arm/xen: Add support for 64KB page granularity

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

[Xen-devel] [PATCH v5 11/22] tty/hvc: xen: Use xen page definition

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

[Xen-devel] [PATCH v5 17/22] net/xen-netfront: Make it running on 64KB page granularity

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

[Xen-devel] [PATCH v5 15/22] block/xen-blkfront: Make it running on 64KB page granularity

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

[Xen-devel] [PATCH v5 14/22] xen/grant-table: Make it running on 64KB granularity

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

Re: [Xen-devel] [PATCH OSSTEST v3 1/3] ts-openstack-deploy: Deploy OpenStack on a host with devstack

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 >>

Re: [Xen-devel] [PATCH DOCDAY] xen: write a high level description of the sub-arch choices for heap layout

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

[Xen-devel] [PATCH v5 22/22] xen/swiotlb: Add support for 64KB page granularity

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

Re: [Xen-devel] [PATCH DOCDAY] xen: write a high level description of the sub-arch choices for heap layout

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

Re: [Xen-devel] [PATCH] xen/arm: Correctly read the GICv3 Re-Distributor stride

> -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

[Xen-devel] [PATCH v3] x86/EPT: work around hardware erratum setting A bit

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

Re: [Xen-devel] [PATCH DOCDAY] xen: write a high level description of the sub-arch choices for heap layout

>>> 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:

Re: [Xen-devel] Xen / EC2 network HVM device visibility

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

Re: [Xen-devel] [PATCH 1/3] x86/p2m: tighten conditions of IOMMU mapping updates

>>> 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

[Xen-devel] [PATCH v5 18/22] net/xen-netback: Make it running on 64KB page granularity

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

Re: [Xen-devel] [PATCH v5 05/22] xen/grant: Add helper gnttab_page_grant_foreign_access_ref_one

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

[Xen-devel] [PATCH v5 10/22] xen/xenbus: Use Xen page definition

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

Re: [Xen-devel] [PATCH V7 2/7] libxl_read_file_contents: add new entry to read sysfs file

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

Re: [Xen-devel] [PATCH v5 00/22] xen/arm64: Add support for 64KB page in Linux

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

Re: [Xen-devel] [PATCH v3] x86/EPT: work around hardware erratum setting A bit

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

Re: [Xen-devel] [PATCH] x86/EPT: defer enabling of A/D maintenance until PML get enabled

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

Re: [Xen-devel] Xen / EC2 network HVM device visibility

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

Re: [Xen-devel] [PATCH v2 for Xen 4.6 5/6] docs: make xl-psr.markdown more precise

> > 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

[Xen-devel] [PATCH v5 07/22] block/xen-blkfront: Store a page rather a pfn in the grant structure

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é

[Xen-devel] [PATCH v5 08/22] block/xen-blkfront: split get_grant in 2

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

[Xen-devel] [PATCH v5 03/22] xen: Add Xen specific page definition

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

[Xen-devel] [PATCH v5 00/22] xen/arm64: Add support for 64KB page in Linux

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

[Xen-devel] [PATCH v5 05/22] xen/grant: Add helper gnttab_page_grant_foreign_access_ref_one

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

[Xen-devel] [PATCH v5 04/22] xen/grant: Introduce helpers to split a page into grant

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

[Xen-devel] [PATCH v5 06/22] block/xen-blkfront: Split blkif_queue_request in 2

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

[Xen-devel] [PATCH v5 09/22] xen/biomerge: Don't allow biovec's to be merged when Linux is not using 4KB pages

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

[Xen-devel] [PATCH v5 02/22] arm/xen: Drop pte_mfn and mfn_pte

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

[Xen-devel] [PATCH v5 01/22] net/xen-netback: xenvif_gop_frag_copy: move GSO check out of the loop

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

Re: [Xen-devel] [PATCH DOCDAY] xen: write a high level description of the sub-arch choices for heap layout

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

Re: [Xen-devel] [PATCH v3] x86/EPT: work around hardware erratum setting A bit

>>> 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.

Re: [Xen-devel] [PATCH v6 24/29] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs

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

Re: [Xen-devel] [PATCH v6 24/29] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs

>>> 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

Re: [Xen-devel] [PATCH] x86/EPT: defer enabling of A/D maintenance until PML get enabled

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,

Re: [Xen-devel] [PATCH v6 24/29] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs

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 *

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

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

Re: [Xen-devel] [PATCH v3] x86/EPT: work around hardware erratum setting A bit

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

Re: [Xen-devel] [PATCH] xen/arm: Correctly read the GICv3 Re-Distributor stride

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;

Re: [Xen-devel] [PATCH v3] x86/EPT: work around hardware erratum setting A bit

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,

[Xen-devel] xen-4.6 compile error

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

Re: [Xen-devel] [PATCH v2] x86/PoD: shorten certain operations on higher order ranges

>>> 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

Re: [Xen-devel] [PATCH v5 00/22] xen/arm64: Add support for 64KB page in Linux

> > 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

[Xen-devel] [PATCH DOCDAY v2] xen: write a high level description of the sub-arch choices for heap layout

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

Re: [Xen-devel] [PATCH v6 24/29] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs

>>> 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; >

[Xen-devel] [distros-debian-snapshot test] 38096: regressions - trouble: broken/fail/pass

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.

[Xen-devel] [qemu-upstream-4.4-testing test] 62491: regressions - FAIL

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

[Xen-devel] [xen-unstable test] 62500: tolerable FAIL - PUSHED

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

[Xen-devel] [distros-debian-squeeze test] 38109: all pass

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

[Xen-devel] [linux-3.14 test] 62520: regressions - FAIL

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

Re: [Xen-devel] [PATCH V7 3/7] libxl: add pvusb API

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 > >

  1   2   >