Re: [Xen-devel] Windows Paravirtualization for Xen

Adding main Xen development list too. On Mon, Nov 10, 2014 at 1:00 PM, hanji unit wrote: > Hello. I am looking at windows Paravirtualization support and I've seen a > few projects including: > > 1) win-pvdrivers by James Harper ( > http://wiki.xen.org/wiki/Xen_Windows_GplPv) > 2) Windows PV-Driv

Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps

--- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -158,14 +158,14 @@ struct iommu_ops { void (*crash_shutdown)(void); void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int page_count); void (*iotlb_flush_all)(struct domain *d); -int (*get_re

Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps

On 2014/11/7 19:08, Jan Beulich wrote: On 07.11.14 at 11:27, wrote: Are you saying Xen restrict some BDFs specific to emulate some devices? But I don't see these associated codes. I didn't say so. All I said that some of the SBDFs are being used by them. --- a/xen/include/xen/iommu.h +++ b/

[Xen-devel] [PATCH V3 6/8] xen: Hide get_phys_to_machine() to be able to tune common path

Today get_phys_to_machine() is always called when the mfn for a pfn is to be obtained. Add a wrapper __pfn_to_mfn() as inline function to be able to avoid calling get_phys_to_machine() when possible as soon as the switch to a linear mapped p2m list has been done. Signed-off-by: Juergen Gross ---

[Xen-devel] [PATCH V3 5/8] x86: Introduce function to get pmd entry pointer

Introduces lookup_pmd_address() to get the address of the pmd entry related to a virtual address in the current address space. This function is needed for support of a virtual mapped sparse p2m list in xen pv domains. Signed-off-by: Juergen Gross --- arch/x86/include/asm/pgtable_types.h | 1 +

[Xen-devel] [PATCH V3 3/8] xen: Delay m2p_override initialization

The m2p overrides are used to be able to find the local pfn for a foreign mfn mapped into the domain. They are used by driver backends having to access frontend data. As this functionality isn't used in early boot it makes no sense to initialize the m2p override functions very early. It can be don

[Xen-devel] [PATCH V3 4/8] xen: Delay invalidating extra memory

When the physical memory configuration is initialized the p2m entries for not pouplated memory pages are set to "invalid". As those pages are beyond the hypervisor built p2m list the p2m tree has to be extended. This patch delays processing the extra memory related p2m entries during the boot proc

[Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped sparse p2m list

At start of the day the Xen hypervisor presents a contiguous mfn list to a pv-domain. In order to support sparse memory this mfn list is accessed via a three level p2m tree built early in the boot process. Whenever the system needs the mfn associated with a pfn this tree is used to find the mfn. I

[Xen-devel] [PATCH V3 1/8] xen: Make functions static

Some functions in arch/x86/xen/p2m.c are used locally only. Make them static. Rearrange the functions in p2m.c to avoid forward declarations. While at it correct some style issues (long lines, use pr_warn()). Signed-off-by: Juergen Gross --- arch/x86/include/asm/xen/page.h | 6 - arch/x86/xen

[Xen-devel] [PATCH V3 8/8] xen: Speed up set_phys_to_machine() by using read-only mappings

Instead of checking at each call of set_phys_to_machine() whether a new p2m page has to be allocated due to writing an entry in a large invalid or identity area, just map those areas read only and react to a page fault on write by allocating the new page. This change will make the common path with

[Xen-devel] [PATCH V3 0/8] xen: Switch to virtual mapped linear p2m list

Paravirtualized kernels running on Xen use a three level tree for translation of guest specific physical addresses to machine global addresses. This p2m tree is used for construction of page table entries, so the p2m tree walk is performance critical. By using a linear virtual mapped p2m list acce

[Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of pv-domain

Early in the boot process the memory layout of a pv-domain is changed to match the E820 map (either the host one for Dom0 or the Xen one) regarding placement of RAM and PCI holes. This requires removing memory pages initially located at positions not suitable for RAM and adding them later at higher

Re: [Xen-devel] [PATCH v0 RFC 0/2] xl/libxl support for PVUSB

On 11/10/2014 04:01 PM, Konrad Rzeszutek Wilk wrote: On Mon, Nov 10, 2014 at 01:37:44AM -0700, Chun Yan Liu wrote: Is there any progress on this work? I didn't see new version after this. Anyone knows the status? I believe Olaf and Juergen were looking at this for Xen 4.6? I'm working on the

Re: [Xen-devel] [PATCH 1/1] PCI: Deletion of unnecessary checks before three function calls

On Sun, Nov 02, 2014 at 04:12:30PM +0100, SF Markus Elfring wrote: > The functions pci_dev_put(), pci_pme_wakeup_bus() and put_device() test > whether their argument is NULL and then return immediately. Thus the test > around the call is not needed. > > This issue was detected by using the Coccine

Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default disables it.

Konrad Rzeszutek Wilk wrote on 2014-11-10: > On Mon, Nov 10, 2014 at 05:08:09AM +, Zhang, Yang Z wrote: >> Konrad Rzeszutek Wilk wrote on 2014-01-16: >>> On Mon, Jan 13, 2014 at 11:51:28AM +, Jan Beulich wrote: >>> On 13.01.14 at 12:38, Ian Campbell > wrote: > On Mon, 2014-01-13 at

[Xen-devel] [linux-linus test] 31471: regressions - FAIL

flight 31471 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31471/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumpuserxen-amd64 8 guest-start fail REGR. vs. 31241 test-amd64-i386-rumpu

Re: [Xen-devel] [PATCH 1/3] x86/xen: Introduce a global flag to fix the MSI mask bug

On 2014/11/11 8:04, Bjorn Helgaas wrote: > On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote: >> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()") >> fixed MSI mask bug which may cause kernel crash. But the commit >> made MSI code complex. Introduce a new global

[Xen-devel] [linux-next test] 31469: tolerable FAIL

flight 31469 linux-next real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31469/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumpuserxen-amd64 8 guest-start fail baseline untested test-amd64-amd64-xl 9

Re: [Xen-devel] [PATCH 1/3] x86/xen: Introduce a global flag to fix the MSI mask bug

On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote: > Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()") > fixed MSI mask bug which may cause kernel crash. But the commit > made MSI code complex. Introduce a new global flag "pci_msi_ignore_mask" > to ignore MSI/MSI

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

flight 31470 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31470/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303 Regressions which are

[Xen-devel] [PATCH 2/2] libxl: Simplify cleanup in do_pci_remove()

Calls to xc_physdev_unmap_pirq() will fail for HVM guests since QEMU makes the same call earlier, during device removal. In addition, guest's call to xc_domain_irq_permission() will also fail since clearing permissions is part of hypervisor's unmap_domain_pirq(). Signed-off-by: Boris Ostrovsky T

[Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down

When a device is hot-unplugged libxl sends QEMU a "device-del" message (via QMP). This call returns after QEMU has initiated device removal by sending an interrupt to the guest. At some point later QEMU is expected to clean up after the device (such as unbind/unmap MSIs), which will occur when the

[Xen-devel] [PATCH 0/2] Two fixes for libxl's PCI detach operation

Two patches to fix 'xl pci-detach'/do_pci_remove() behavior. * Prevent libxl from resetting device (and removing it from xenstore) before QEMU responded to the guest's 'eject' write * Remove unnecessary calls to xc_physdev_unmap_pirq() and xc_domain_irq_permission() If patches are acceptable

Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.

On 11/10/2014 07:01 AM, Ian Campbell wrote: On Thu, 2014-11-06 at 17:01 -0500, Daniel De Graaf wrote: On 11/04/2014 05:15 AM, Ian Campbell wrote: On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote: Of course we can use max, but I thought that it might be useful to have a prink to inform the

[Xen-devel] [seabios test] 31463: regressions - FAIL

flight 31463 seabios real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31463/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 30767 build-amd64-pvops

Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug (BAR64 addresses are bogus)

On Mon, Nov 10, 2014 at 01:07:20PM -0500, Konrad Rzeszutek Wilk wrote: > On Mon, Nov 10, 2014 at 05:42:32PM +, David Vrabel wrote: > > On 10/11/14 17:32, Konrad Rzeszutek Wilk wrote: > > > Hey, > > > > > > With Xen 4.5 (today's staging), when I boot a guest and then do pci-attach > > > the BAR

Re: [Xen-devel] [PATCH for Xen 4.5 v3 0/2] Sanity check input and serialize vcpu data in sched_rt.c

Sorry, the cover letter missed one line. :-( 2014-11-10 16:11 GMT-05:00 Meng Xu : These two patches are to solve the issues found by Jan Beulich at http://lists.xen.org/archives/html/xen-devel/2014-09/msg03554.html. The solution is summarized by Dario Faggioli at > http://lists.xen.org/archives/

[Xen-devel] [PATCH for Xen 4.5 v3 1/2] xen: sanity check input and serialization in sched_rt.c

Sanity check input params in rt_dom_cntl(); Serialize rt_dom_cntl() against the global lock. Signed-off-by: Meng Xu Reviewed-by: Dario Faggioli Reviewed-by: George Dunlap --- xen/common/sched_rt.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/xen/common/sched_rt.c b/xen/co

[Xen-devel] [PATCH for Xen 4.5 v3 2/2] xen: serialize vcpu data in sched_rt.c

Fix the following two issues in rtds scheduler: 1) The runq queue lock is not grabbed when rt_update_deadline is called in rt_alloc_vdata function, which may cause race condition; Solution: Move call to rt_update_deadline from _alloc to _insert; Note: rt_alloc_vdata does not need grab the runq lock

[Xen-devel] [PATCH for Xen 4.5 v3 0/2] Sanity check input and serialize vcpu data in sched_rt.c

The solution is summarized by Dario Faggioli at http://lists.xen.org/archives/html/xen-devel/2014-09/msg03603.html. Here is the solution: - sanity checking input params in rt_dom_cntl() - serialize rt_dom_cntl() itself against the global lock - move the call to rt_update_deadline()

Re: [Xen-devel] [for-xen-4.5 v9 2/2] dpci: Replace tasklet with an softirq (v12)

On Tue, Nov 04, 2014 at 10:37:29AM +, Jan Beulich wrote: > >>> On 03.11.14 at 20:14, wrote: > > +/* > > + * Should only be called from hvm_do_IRQ_dpci. We use the > > This statement together with the comment in pt_pirq_softirq_active() > is at least confusing: If the function is to be called

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

flight 31462 linux-3.14 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31462/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 9 guest-start fail REGR. vs. 30755 Tests which are failin

Re: [Xen-devel] Regression, host crash with 4.5rc1

On 11/10/2014 0:51, Jan Beulich wrote: On 10.11.14 at 09:03, wrote: Sorry for the delay, took some debugging on another computer to get serial logging working. Due to its size, I've posted the entire log of a crashed session here: http://pastebin.com/AiPHUZRH In this case I used a 3.0 gig memor

[Xen-devel] CfP for LF Collab Summit

See http://events.linuxfoundation.org/events/collaboration-summit/program/cfp As an aside: * I arranged for 1/2 day public Xen track * And a 1/2 day of space for private meetings for members of the Xen community planning to come to Collab Summit Regards Lars_

[Xen-devel] [qemu-mainline test] 31468: regressions - FAIL

flight 31468 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31468/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 9 guest-start fail REGR. vs. 30603 test-amd64-i386-pai

Re: [Xen-devel] [PATCH v8 0/13] introduce GNTTABOP_cache_flush

On Mon, Nov 10, 2014 at 04:12:40PM +, Stefano Stabellini wrote: > this patch series introduces support for GNTTABOP_cache_flush to perform > cache maintenance operation on foreign pages and reverts the current > code based on XENFEAT_grant_map_identity. > > It also provides a very slow fallbac

Re: [Xen-devel] [PATCH v8 04/13] arm64: introduce is_device_dma_coherent

On Mon, Nov 10, 2014 at 04:13:56PM +, Stefano Stabellini wrote: > Introduce a boolean flag and an accessor function to check whether a > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops. > > Signed-off-by: Stefano Stabellini > Signed-off-by: Catalin Marinas BTW, why do I

Re: [Xen-devel] [PATCH v8 03/13] xen/arm: if(pfn_valid(pfn)) call native dma_ops

On Mon, Nov 10, 2014 at 04:13:55PM +, Stefano Stabellini wrote: > void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle, > size_t size, enum dma_data_direction dir, > - struct dma_attrs *attrs); > + struct dma_attrs *attrs) > +{ > + unsigned

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson wrote: > Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 > process post-mortem"): >> On this point in particular, back in 2012 [1] I suggested that all >> membership requests should be discussed in public on a community email

Re: [Xen-devel] [PATCH v8 10/13] xen/arm/arm64: introduce xen_arch_need_swiotlb

On Mon, Nov 10, 2014 at 04:14:02PM +, Stefano Stabellini wrote: > --- a/arch/arm/include/asm/xen/page.h > +++ b/arch/arm/include/asm/xen/page.h > @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, > unsigned long mfn) > #define xen_remap(cookie, size) ioremap_cache(

Re: [Xen-devel] [PATCH v8 09/13] xen/arm/arm64: merge xen/mm32.c into xen/mm.c

On Mon, Nov 10, 2014 at 04:14:01PM +, Stefano Stabellini wrote: > --- a/arch/arm/xen/mm.c > +++ b/arch/arm/xen/mm.c > @@ -1,6 +1,10 @@ > +#include > +#include > #include > #include > +#include > #include > +#include > #include > #include > #include > @@ -16,6 +20,88 @@ > #inclu

Re: [Xen-devel] [PATCH v8 08/13] xen/arm: use hypercall to flush caches in map_page

On Mon, Nov 10, 2014 at 04:14:00PM +, Stefano Stabellini wrote: > In xen_dma_map_page, if the page is a local page, call the native > map_page dma_ops. If the page is foreign, call __xen_dma_map_page that > issues any required cache maintenane operations via hypercall. > > The reason for doing

Re: [Xen-devel] [PATCH v8 07/13] xen: add a dma_addr_t dev_addr argument to xen_dma_map_page

On Mon, Nov 10, 2014 at 04:13:59PM +, Stefano Stabellini wrote: > Signed-off-by: Stefano Stabellini > CC: david.vra...@citrix.com > CC: konrad.w...@oracle.com > --- > arch/arm/include/asm/xen/page-coherent.h |4 ++-- > arch/arm64/include/asm/xen/page-coherent.h |4 ++-- > arch/x86/i

Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug (BAR64 addresses are bogus)

On Mon, Nov 10, 2014 at 05:42:32PM +, David Vrabel wrote: > On 10/11/14 17:32, Konrad Rzeszutek Wilk wrote: > > Hey, > > > > With Xen 4.5 (today's staging), when I boot a guest and then do pci-attach > > the BARs values are corrupt. > > Corrupt? > > > [ 152.572965] pci :00:04.0: BAR 1:

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

George Dunlap writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson > > Such a system would (a) be unworkable in practice, because no-one > > really cares about this kind of tedious makework, and (b) at serious > > risk

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

Having gone through the thread, I've prepared a three-part new proposal email. I. Deployment with Security Team Permission II. Predisclosure list memembership III. Information sharing IV. Fixes which seem to have rough consensus as they were Perhaps I should be checking the current web page out a

Re: [Xen-devel] xl list -l doesn't work for incoming domain

On 11/10/2014 12:24 PM, Wei Liu wrote: > On Mon, Nov 10, 2014 at 12:08:18PM -0500, Zhigang Wang wrote: >> On 11/10/2014 10:25 AM, Wei Liu wrote: >>> On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote: On 11/10/2014 07:35 AM, Wei Liu wrote: > I see. At that point the configuration

Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug (BAR64 addresses are bogus)

On 10/11/14 17:32, Konrad Rzeszutek Wilk wrote: > Hey, > > With Xen 4.5 (today's staging), when I boot a guest and then do pci-attach > the BARs values are corrupt. Corrupt? > [ 152.572965] pci :00:04.0: BAR 1: no space for [mem size 0x0800 > 64bit pref] Looks like the default MMIO h

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > On Wed, Oct 22, 2014 at 02:05:38PM +0100, Lars Kurth wrote: > > The changes on the table are really more practical and aim at > > demonstrating a) use of Xen and b) a mature security vulnerability >

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

Bastian Blank writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > On Thu, Oct 09, 2014 at 12:06:23AM +0100, Ian Jackson wrote: > > The -discuss list is moderated by the Xen Project Security Team. > > Announcements of private availability of fixed versions, a

[Xen-devel] PCI passthrough (pci-attach) to HVM guests bug (BAR64 addresses are bogus)

Hey, With Xen 4.5 (today's staging), when I boot a guest and then do pci-attach the BARs values are corrupt. For example, with this guest config: kernel="hvmloader" builder="hvm" serial="pty" memory = 2048 name = "XTT" usb=1 usbdevice='tablet' vcpus=2 vga="stdvga" vif = [ 'mac=00:0f:4b:00:00:63,

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > On this point in particular, back in 2012 [1] I suggested that all > membership requests should be discussed in public on a community email > list like xen-devel, or another email list to avoid nois

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > I also was wondering whether it would make sense to put a time-limit > on applications. For example, we could say that processing an > application will take 2 weeks. By doing so, we avoid having to >

Re: [Xen-devel] xl list -l doesn't work for incoming domain

On Mon, Nov 10, 2014 at 12:08:18PM -0500, Zhigang Wang wrote: > On 11/10/2014 10:25 AM, Wei Liu wrote: > > On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote: > >> On 11/10/2014 07:35 AM, Wei Liu wrote: > >>> I see. At that point the configuration was not available, yet. After the > >>> d

Re: [Xen-devel] BUG in xennet_make_frags with paged skb data

2014-11-10 16:42 GMT+00:00 David Vrabel : > On 10/11/14 16:39, Zoltan Kiss wrote: > > > > The BUG_ON suggested by Stefan would be still reasonable: > > > > BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len > > > PAGE_SIZE< > Well, it wouldn't trigger but I don't think it is useful any more.

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

Jan Beulich writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > There's one more thing I thought of btw: When we change the > policy following whatever community input we gathered (not just > now, but also in the future), people currently on the pre-disclosure >

Re: [Xen-devel] xl list -l doesn't work for incoming domain

On 11/10/2014 10:25 AM, Wei Liu wrote: > On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote: >> On 11/10/2014 07:35 AM, Wei Liu wrote: >>> I see. At that point the configuration was not available, yet. After the >>> domain is successfully migrated, the configuration should be available. >

Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design

On Mon, Nov 10, 2014 at 8:17 AM, Chunyan Liu wrote: > > 3. Function Implementation > >libxl_domain_snapshot_create: >1). check args validation >2). save domain memory through save-domain >3). take disk snapshot by qmp command (if domian is active) or qemu-img >

Re: [Xen-devel] BUG in xennet_make_frags with paged skb data

On Mon, 2014-11-10 at 16:42 +, David Vrabel wrote: > On 10/11/14 16:39, Zoltan Kiss wrote: > > > > The BUG_ON suggested by Stefan would be still reasonable: > > > > BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len > > > PAGE_SIZE< > Well, it wouldn't trigger but I don't think it is u

Re: [Xen-devel] BUG in xennet_make_frags with paged skb data

On 10/11/14 14:41, David Vrabel wrote: On 10/11/14 14:35, Seth Forshee wrote: On Fri, Nov 07, 2014 at 10:44:15AM +, David Vrabel wrote: On 06/11/14 21:49, Seth Forshee wrote: We've had several reports of hitting the following BUG_ON in xennet_make_frags with 3.2 and 3.13 kernels (I'm cur

Re: [Xen-devel] BUG in xennet_make_frags with paged skb data

On 10/11/14 16:39, Zoltan Kiss wrote: > > The BUG_ON suggested by Stefan would be still reasonable: > > BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len > > PAGE_SIZE

[Xen-devel] [xen-4.2-testing test] 31461: regressions - FAIL

flight 31461 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31461/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594 Tests whi

[Xen-devel] [PATCH v8 11/13] xen/arm: introduce GNTTABOP_cache_flush

Introduce support for new hypercall GNTTABOP_cache_flush. Use it to perform cache flashing on pages used for dma when necessary. If GNTTABOP_cache_flush is supported by the hypervisor, we don't need to bounce dma map operations that involve foreign grants and non-coherent devices. Signed-off-by:

[Xen-devel] [PATCH v8 12/13] swiotlb-xen: pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu

xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t handle as argument, not a physical address. Signed-off-by: Stefano Stabellini --- drivers/xen/swiotlb-xen.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/sw

[Xen-devel] [PATCH v8 13/13] swiotlb-xen: remove BUG_ON in xen_bus_to_phys

On x86 truncation cannot occur because config XEN depends on X86_64 || (X86_32 && X86_PAE). On ARM truncation can occur without CONFIG_ARM_LPAE, when the dma operation involves foreign grants. However in that case the physical address returned by xen_bus_to_phys is actually invalid (there is no mf

[Xen-devel] [PATCH v8 07/13] xen: add a dma_addr_t dev_addr argument to xen_dma_map_page

Signed-off-by: Stefano Stabellini CC: david.vra...@citrix.com CC: konrad.w...@oracle.com --- arch/arm/include/asm/xen/page-coherent.h |4 ++-- arch/arm64/include/asm/xen/page-coherent.h |4 ++-- arch/x86/include/asm/xen/page-coherent.h |4 ++-- drivers/xen/swiotlb-xen.c

[Xen-devel] [PATCH v8 09/13] xen/arm/arm64: merge xen/mm32.c into xen/mm.c

Merge xen/mm32.c into xen/mm.c. As a consequence the code gets compiled on arm64 too. Signed-off-by: Stefano Stabellini --- arch/arm/xen/Makefile |2 +- arch/arm/xen/mm.c | 86 + arch/arm/xen/mm32.c

[Xen-devel] [PATCH v8 04/13] arm64: introduce is_device_dma_coherent

Introduce a boolean flag and an accessor function to check whether a device is dma_coherent. Set the flag from set_arch_dma_coherent_ops. Signed-off-by: Stefano Stabellini Signed-off-by: Catalin Marinas CC: will.dea...@arm.com --- arch/arm64/include/asm/device.h |1 + arch/arm64/includ

[Xen-devel] [PATCH v8 02/13] xen/arm: remove outer_*_range call

Dom0 is not actually capable of issuing outer_inv_range or outer_clean_range calls. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- arch/arm/xen/mm32.c |9 - 1 file changed, 9 deletions(-) diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c index a5a93fc..6153d61 10

[Xen-devel] [PATCH v8 08/13] xen/arm: use hypercall to flush caches in map_page

In xen_dma_map_page, if the page is a local page, call the native map_page dma_ops. If the page is foreign, call __xen_dma_map_page that issues any required cache maintenane operations via hypercall. The reason for doing this is that the native dma_ops map_page could allocate buffers than need to

Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data in sched_rt.c

On 11/10/2014 04:04 PM, Meng Xu wrote: 2014-11-10 10:40 GMT-05:00 George Dunlap mailto:george.dun...@eu.citrix.com>>: On 11/10/2014 03:29 PM, Meng Xu wrote: I'm not sure if I should resend the patch just to change the commit log and add the reason of why doing this. I want to

[Xen-devel] [PATCH v8 05/13] arm: introduce is_device_dma_coherent

Introduce a boolean flag and an accessor function to check whether a device is dma_coherent. Set the flag from set_arch_dma_coherent_ops. Signed-off-by: Stefano Stabellini Signed-off-by: Catalin Marinas CC: li...@arm.linux.org.uk CC: will.dea...@arm.com --- arch/arm/include/asm/device.h |

[Xen-devel] [PATCH v8 06/13] xen/arm: use is_device_dma_coherent

Use is_device_dma_coherent to check whether we need to issue cache maintenance operations rather than checking on the existence of a particular dma_ops function for the device. This is correct because coherent devices don't need cache maintenance operations - arm_coherent_dma_ops does not set the

[Xen-devel] [PATCH v8 03/13] xen/arm: if(pfn_valid(pfn)) call native dma_ops

Remove code duplication in mm32.c by calling the native dma_ops if the page is a local page (not a foreign page). Use a simple pfn_valid(pfn) check to figure out if the page is local, exploiting the fact that dom0 is mapped 1:1, therefore pfn_valid always returns false when called on a foreign mfn.

[Xen-devel] [PATCH v8 10/13] xen/arm/arm64: introduce xen_arch_need_swiotlb

Introduce an arch specific function to find out whether a particular dma mapping operation needs to bounce on the swiotlb buffer. On ARM and ARM64, if the page involved is a foreign page and the device is not coherent, we need to bounce because at unmap time we cannot execute any required cache ma

[Xen-devel] [PATCH v8 01/13] xen/arm: remove handling of XENFEAT_grant_map_identity

The feature has been removed from Xen. Also Linux cannot use it on ARM32 without CONFIG_ARM_LPAE. Signed-off-by: Stefano Stabellini Reviewed-by: David Vrabel Acked-by: Ian Campbell --- Changes in v2: - remove the definition of XENFEAT_grant_map_identity. --- arch/arm/xen/enlighten.c

[Xen-devel] [PATCH v8 0/13] introduce GNTTABOP_cache_flush

Hi all, this patch series introduces support for GNTTABOP_cache_flush to perform cache maintenance operation on foreign pages and reverts the current code based on XENFEAT_grant_map_identity. It also provides a very slow fallback by bouncing on the swiotlb buffer, in case the hypercall is not avai

Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data in sched_rt.c

2014-11-10 10:40 GMT-05:00 George Dunlap : > On 11/10/2014 03:29 PM, Meng Xu wrote: > > I'm not sure if I should resend the patch just to change the commit log > and add the reason of why doing this. > > I want to first add the reason. If I should resend the patch set, please > let me know. > >

Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data in sched_rt.c

On 11/10/2014 03:29 PM, Meng Xu wrote: I'm not sure if I should resend the patch just to change the commit log and add the reason of why doing this. I want to first add the reason. If I should resend the patch set, please let me know. 2014-11-10 7:53 GMT-05:00 George Dunlap mailto:george.dun...

Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode to guest

On Mon, 2014-11-10 at 13:43 +, Wei Liu wrote: > To summarise this discussion so far. > > Conceptually speaking, the guest should not need to know the mapping. > The translation from vnode to pnode should happen in hypervisor without > guest knowing. > > Jan, Dario and David (and I) are all in

Re: [Xen-devel] xl mem-max error

OK. Let me try my best: >>> I'm confused by the description of what's going on, in particular the >>> mixing of mem-max commands and target xenstore nodes (since the former >>> doesn't really affect the latter). >>> >>> How was the domain started (memory= and maxmem=). xl create with 'memory = 70

Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data in sched_rt.c

On 11/10/2014 03:36 PM, Dario Faggioli wrote: On Mon, 2014-11-10 at 10:29 -0500, Meng Xu wrote: I'm not sure if I should resend the patch just to change the commit log and add the reason of why doing this. Yes, that is usually quite a good reason, as changelogs are really important (for the re

Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data in sched_rt.c

On Mon, 2014-11-10 at 10:29 -0500, Meng Xu wrote: > I'm not sure if I should resend the patch just to change the commit > log and add the reason of why doing this. > Yes, that is usually quite a good reason, as changelogs are really important (for the reasons George pointed out already). Sometim

Re: [Xen-devel] xl mem-max error

On Mon, 2014-11-10 at 10:29 -0500, Zhigang Wang wrote: > On 11/10/2014 07:44 AM, Ian Campbell wrote: > > On Mon, 2014-11-10 at 12:37 +, Wei Liu wrote: > > > >> Ian and Ian, any thought how this bug came into being? I think we should > >> fix this for 4.5, but I don't think I know enough of how

Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data in sched_rt.c

I'm not sure if I should resend the patch just to change the commit log and add the reason of why doing this. I want to first add the reason. If I should resend the patch set, please let me know. 2014-11-10 7:53 GMT-05:00 George Dunlap : > On 10/25/2014 03:16 PM, Meng Xu wrote: > >> Move call to

Re: [Xen-devel] xl mem-max error

On 11/10/2014 07:44 AM, Ian Campbell wrote: > On Mon, 2014-11-10 at 12:37 +, Wei Liu wrote: > >> Ian and Ian, any thought how this bug came into being? I think we should >> fix this for 4.5, but I don't think I know enough of how memory target >> is expected to behave. >> > > I'm confused by

Re: [Xen-devel] xl list -l doesn't work for incoming domain

On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote: > On 11/10/2014 07:35 AM, Wei Liu wrote: > > I see. At that point the configuration was not available, yet. After the > > domain is successfully migrated, the configuration should be available. > > > > I think a domain under constructio

[Xen-devel] Xen 4.5 RC2 (scheduled on the 12th). Committeers - please read.

Hey, The 'staging' has four extra patches: e6fa63d pvgrub: ignore NUL fda1614 xen/arm: Add support for GICv3 for domU 5a430ec tools: libxl: do not overrun input buffer in libxl__parse_mac 379b351 tools: libxl: do not leak diskpath during local disk attach where the ' xen/arm: Add support for GIC

Re: [Xen-devel] xl list -l doesn't work for incoming domain

On 11/10/2014 07:35 AM, Wei Liu wrote: > I see. At that point the configuration was not available, yet. After the > domain is successfully migrated, the configuration should be available. > > I think a domain under construction without domain configuration is a > valid state. What do you think? H

Re: [Xen-devel] [PATCH v0 RFC 0/2] xl/libxl support for PVUSB

On Mon, Nov 10, 2014 at 01:37:44AM -0700, Chun Yan Liu wrote: > Is there any progress on this work? I didn't see new version after this. > Anyone knows the status? I believe Olaf and Juergen were looking at this for Xen 4.6? CC-ing them. > > Thanks, > Chunyan > > >>> On 8/11/2014 at 04:23 AM, i

Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default disables it.

On Mon, Nov 10, 2014 at 05:08:09AM +, Zhang, Yang Z wrote: > Konrad Rzeszutek Wilk wrote on 2014-01-16: > > On Mon, Jan 13, 2014 at 11:51:28AM +, Jan Beulich wrote: > > On 13.01.14 at 12:38, Ian Campbell wrote: > >>> On Mon, 2014-01-13 at 11:30 +, Jan Beulich wrote: > In fact

Re: [Xen-devel] [PATCH v3] x86/hvm: Add per-vcpu evtchn upcalls

On 10/11/14 11:13, Paul Durrant wrote: > HVM guests have always been confined to using the domain callback > via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications. > This is usually an IOAPIC vector and is only used if the event > channel is bound to vcpu 0. > > PV-on-HVM Linux uses a lo

Re: [Xen-devel] [PATCH OSSTEST] Debian: Install ethtool on the hosts [and 2 more messages]

Ian Campbell writes ("[PATCH OSSTEST] Debian: Install ethtool on the hosts"): > It's very useful when debugging network issues. Ian Campbell writes ("[PATCH OSSTEST] mg-debian-installer-update: Use Packages.gz"): > In Jessie Packages.bz2 is replaced by Packages.xz. Rather than implementing > per-

Re: [Xen-devel] BUG in xennet_make_frags with paged skb data

On 10/11/14 14:35, Seth Forshee wrote: > On Fri, Nov 07, 2014 at 10:44:15AM +, David Vrabel wrote: >> On 06/11/14 21:49, Seth Forshee wrote: >>> We've had several reports of hitting the following BUG_ON in >>> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting >>> results of te

Re: [Xen-devel] BUG in xennet_make_frags with paged skb data

On Fri, Nov 07, 2014 at 10:44:15AM +, David Vrabel wrote: > On 06/11/14 21:49, Seth Forshee wrote: > > We've had several reports of hitting the following BUG_ON in > > xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting > > results of testing with 3.17): > > > > /* Gran

Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.

On Mon, Nov 10, 2014 at 12:01:59PM +, Ian Campbell wrote: > On Thu, 2014-11-06 at 17:01 -0500, Daniel De Graaf wrote: > > On 11/04/2014 05:15 AM, Ian Campbell wrote: > > > On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote: > > >> Of course we can use max, but I thought that it might be usef

Re: [Xen-devel] How to run a HVM guest without pv

On Mon, Nov 10, 2014 at 08:11:56PM +0800, Wen Congyang wrote: > On 11/10/2014 07:50 PM, Stefano Stabellini wrote: > > On Mon, 10 Nov 2014, Wen Congyang wrote: > >> I disable xen-platform-pci in the config file, but when I start the guest, > >> I found > >> the following kernel message: > >> [0

Re: [Xen-devel] xl list -l doesn't work for incoming domain

On Mon, Nov 10, 2014 at 02:05:49PM +, Ian Campbell wrote: > On Mon, 2014-11-10 at 13:54 +, Wei Liu wrote: > > > Can we write a stub json file at the beginning of migrate receive, a bit > > > like we do on create? > > > > > > > No, we don't generate stub for normal domain at the moment. >

[Xen-devel] [libvirt test] 31465: tolerable FAIL - PUSHED

flight 31465 libvirt real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31465/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start

[Xen-devel] [PATCH 3/4] Select correct dom0 console depending on whether Xen is enabled or not

Signed-off-by: Ian Campbell --- configure.ac |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 2f31fab..d292f4d 100644 --- a/configure.ac +++ b/configure.ac @@ -75,7 +75,8 @@ AC_ARG_WITH([initrd], AC_SUBST([FILESYSTEM], [$USE_INITRD]) AM_

  1   2   >