flight 31489 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31489/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl 9 guest-start fail like 31473
test-amd64-i386-pair1
>>> On 12.11.14 at 02:36, wrote:
> On 2014/11/11 18:07, Jan Beulich wrote:
> On 11.11.14 at 10:42, wrote:
>>> On 2014/11/11 17:06, Jan Beulich wrote:
Part of which would involve re-considering whether device
assignment shouldn't be done before memory population in the
tool stac
#2 flags field in each specific device of new domctl would control
whether this device need to check/reserve its own RMRR range. But its
not dependent on current device assignment domctl, so the user can use
them to control which devices need to work as hotplug later, separately.
And this could
>>> On 12.11.14 at 04:05, wrote:
> I don't see any feedback to this point, so I think you still prefer we
> should do all check in the callback function.
As a draft this looks reasonable, but there are various bugs to be
dealt with along with cosmetic issues (I'll point out the former, but
I'm t
>>> On 12.11.14 at 09:45, wrote:
>> > #2 flags field in each specific device of new domctl would control
>>> whether this device need to check/reserve its own RMRR range. But its
>>> not dependent on current device assignment domctl, so the user can use
>>> them to control which devices need to wo
On 2014/11/12 17:02, Jan Beulich wrote:
On 12.11.14 at 09:45, wrote:
#2 flags field in each specific device of new domctl would control
whether this device need to check/reserve its own RMRR range. But its
not dependent on current device assignment domctl, so the user can use
them to control whi
On Tue, 11 Nov 2014, Bjorn Helgaas wrote:
> [+cc Sebastian, linux-s390, David, Konrad, xen-devel]
>
> On Mon, Oct 27, 2014 at 10:44:35AM +0800, Yijing Wang wrote:
> >
> > Yijing Wang (3):
> > x86/xen: Introduce a global flag to fix the MSI mask bug
> > x86/xen: Revert "PCI: Add x86_msi.msi_ma
>>> On 12.11.14 at 02:37, wrote:
> When we PCI insert an device, the BARs are not set at all - and hence
> the Linux kernel is the one that tries to set the BARs in. The
> reason it cannot fit the device in the MMIO region is due to the
> _CRS only having certain ranges (even thought the MMIO regi
>>> On 11.11.14 at 19:03, wrote:
> On 11/11/14 17:36, Wei Liu wrote:
>> Option #1 requires less modification to guest, because guest won't
>> need to switch to new hypercall. It's unclear at this point if a guest
>> asks to populate a gpfn that doesn't belong to any vnode, what Xen
>> should do ab
>>> On 12.11.14 at 07:58, wrote:
> 2. Failed to hotplug a VT-d device with XEN4.5-RC1
> http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
First of all I'm not sure it is really useful to use the old, discontinued
bugzilla to report bugs. I think it would be much easier if y
Am Dienstag 11 November 2014, 15:21:01 schrieb Juergen Gross:
> Hi again,
>
> On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
> > Hi list,
> >
> > When creating a cpupool, starting and destroying a guest within this pool,
> > then removing this pool doesn't work because of EBUSY.
> >
> > It seems the
>>> On 12.11.14 at 10:13, wrote:
> On 2014/11/12 17:02, Jan Beulich wrote:
> On 12.11.14 at 09:45, wrote:
> #2 flags field in each specific device of new domctl would control
> whether this device need to check/reserve its own RMRR range. But its
> not dependent on current device
Il 12/11/2014 07:58, Hu, Robert ha scritto:
Hi All,
This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
Test environment:
Xen: Xen 4.5-rc1
Dom0: Linux kernel 3.17.0
Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP
New bugs(9):
1. with "xen_platform_pci=0" opt
On Tue, 2014-11-11 at 13:46 +, Wei Liu wrote:
> Signed-off-by: Wei Liu
> Cc: Ian Campbell
> Cc: Ian Jackson
> Cc: George Dunlap
> Cc: Konrad Wilk
> ---
> This is a simple enough bug fix I think it should just go in.
Probably, but can you explain in the commit log what the symptoms of not
On 12/11/14 09:24, Jan Beulich wrote:
On 12.11.14 at 02:37, wrote:
>> When we PCI insert an device, the BARs are not set at all - and hence
>> the Linux kernel is the one that tries to set the BARs in. The
>> reason it cannot fit the device in the MMIO region is due to the
>> _CRS only having
On Tue, 2014-11-11 at 17:50 +0100, Julien Grall wrote:
> Hi,
>
> Somehow I missed this email.
>
> On 30/10/2014 13:33, Ian Campbell wrote:
> > create !
> > title it arm: domain 0 disables clocks which are in fact being used
> > thanks
> >
> > On Wed, 2014-10-29 at 16:39 +, Ian Jackson wrote:
>>> On 12.11.14 at 11:01, wrote:
> As for the CRS regions: These typically describe the BIOS set limits in
> hardware configuration for the MMIO hole itself. On single socket
> systems anything which isn't RAM or another predefined region decodes to
> MMIO. This is probably why Jan's Dell system h
On 2014/11/12 17:56, Jan Beulich wrote:
On 12.11.14 at 10:13, wrote:
On 2014/11/12 17:02, Jan Beulich wrote:
On 12.11.14 at 09:45, wrote:
#2 flags field in each specific device of new domctl would control
whether this device need to check/reserve its own RMRR range. But its
not dependent on
On 2014/11/12 16:55, Jan Beulich wrote:
On 12.11.14 at 04:05, wrote:
I don't see any feedback to this point, so I think you still prefer we
should do all check in the callback function.
As a draft this looks reasonable, but there are various bugs to be
dealt with along with cosmetic issues (I
>>> On 12.11.14 at 11:18, wrote:
> On 2014/11/12 16:55, Jan Beulich wrote:
> On 12.11.14 at 04:05, wrote:
>>> I don't see any feedback to this point, so I think you still prefer we
>>> should do all check in the callback function.
>>
>> As a draft this looks reasonable, but there are various
On 11/12/2014 10:53 AM, Dietmar Hahn wrote:
Am Dienstag 11 November 2014, 15:21:01 schrieb Juergen Gross:
Hi again,
On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
Hi list,
When creating a cpupool, starting and destroying a guest within this pool,
then removing this pool doesn't work because of E
Il 06/11/2014 16:12, Fabio Fantoni ha scritto:
Il 03/11/2014 17:03, Konrad Rzeszutek Wilk ha scritto:
On Mon, Nov 03, 2014 at 12:05:44PM +0100, Fabio Fantoni wrote:
Il 31/10/2014 15:33, Konrad Rzeszutek Wilk ha scritto:
I always posted all versions of the patch in xen-devel, the latest
was lon
On 2014/11/12 18:24, Jan Beulich wrote:
On 12.11.14 at 11:18, wrote:
On 2014/11/12 16:55, Jan Beulich wrote:
On 12.11.14 at 04:05, wrote:
I don't see any feedback to this point, so I think you still prefer we
should do all check in the callback function.
As a draft this looks reasonable, b
On Tue, 2014-11-11 at 19:41 +, Ian Jackson wrote:
> Here, I'm trying to fix the way that osstest gets far too obsessed
> about particular failing hosts.
All fine by me, not that I've really grokked the bits towards the end.
(I will try to if you want)
>
> 1/9 cs-adjust-flight: Fix doc about
On Wed, Nov 12, 2014 at 10:01:24AM +, Ian Campbell wrote:
> On Tue, 2014-11-11 at 13:46 +, Wei Liu wrote:
> > Signed-off-by: Wei Liu
> > Cc: Ian Campbell
> > Cc: Ian Jackson
> > Cc: George Dunlap
> > Cc: Konrad Wilk
> > ---
> > This is a simple enough bug fix I think it should just go
Am Mittwoch 12 November 2014, 11:25:14 schrieb Juergen Gross:
> On 11/12/2014 10:53 AM, Dietmar Hahn wrote:
> > Am Dienstag 11 November 2014, 15:21:01 schrieb Juergen Gross:
> >> Hi again,
> >>
> >> On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
> >>> Hi list,
> >>>
> >>> When creating a cpupool, star
... otherwise when device add operation fails, the error message looks
like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
device", which is not very helpful.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
tools/libxl/libxl.c |1 +
1 file changed, 1 inse
Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
cpupool0 before destroying it) introduced an error in the accounting
of cpupools regarding the number of domains. The number of domains
is nor adjusted when a domain is moved to cpupool0 in kill_domain().
Correct this by introducing a
On 12/11/14 10:11, Jan Beulich wrote:
On 12.11.14 at 11:01, wrote:
>> As for the CRS regions: These typically describe the BIOS set limits in
>> hardware configuration for the MMIO hole itself. On single socket
>> systems anything which isn't RAM or another predefined region decodes to
>> MMI
On 12/11/14 10:40, Juergen Gross wrote:
> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> cpupool0 before destroying it) introduced an error in the accounting
> of cpupools regarding the number of domains. The number of domains
> is nor adjusted when a domain is moved to cpupool0
Best Regards,
Robert Ho
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, November 12, 2014 5:49 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; Konrad Rzeszutek Wilk
> Subject: Re: [TestDay] VMX test report for Xen 4.5.0-rc1
>
> >>> On 12.11.14 a
On Wed, 2014-11-12 at 10:39 +, Wei Liu wrote:
> ... otherwise when device add operation fails, the error message looks
> like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
> device", which is not very helpful.
Thanks.
>
> Signed-off-by: Wei Liu
Acked-by: Ian Campbell
On Tue, 2014-11-11 at 21:24 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 08:28:38PM +, M A Young wrote:
> > The build of xen-4.5.0-rc2 fails if XSM_ENABLE=y due to an inconsistency in
> > commit fda1614 "xen/arm: Add support for GICv3 for domU" which uses
> > XEN_DOMCTL_configu
And of course this is v2 of this patch. Sorry for not having added that
in the subject line.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 12.11.14 at 11:46, wrote:
> On 12/11/14 10:40, Juergen Gross wrote:
>> --- a/xen/common/cpupool.c
>> +++ b/xen/common/cpupool.c
>> @@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
>> }
>>
>> /*
>> + * Move domain to another cpupool
>> + */
>> +static int cpupool_move_d
On 11/12/2014 11:46 AM, Andrew Cooper wrote:
On 12/11/14 10:40, Juergen Gross wrote:
Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
cpupool0 before destroying it) introduced an error in the accounting
of cpupools regarding the number of domains. The number of domains
is nor adju
>>> On 12.11.14 at 11:53, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >>> On 12.11.14 at 07:58, wrote:
>> > 4. Not all PFs are available if assign multi VT-d devices to Wndows guest
>> > VM
>> > http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
>>
>> I think
The `if' statement considered return value 0 from libxl_domain_info an
error, while 0 actually means success.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
This is a bug fix for PSR feature. This feature was added recently and it's
not an regression. However, it would be good to h
Ping?
> ... instead of hardcoding values and guess where they config files may
> be. Also use the result of --with-sysconfig-leaf-dir.
>
> Signed-off-by: Olaf Hering
> Cc: Ian Campbell
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Wei Liu
> ---
> tools/hotplug/Linux/init.d/xencommons.in
On Wed, Nov 12, 2014 at 06:58:49AM +, Hu, Robert wrote:
> Hi All,
>
> This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
>
> 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
> http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
See <1415790358
Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
cpupool0 before destroying it) introduced an error in the accounting
of cpupools regarding the number of domains. The number of domains
is nor adjusted when a domain is moved to cpupool0 in kill_domain().
Correct this by introducing a
On Wed, Nov 12, 2014 at 10:40 AM, Juergen Gross wrote:
> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> cpupool0 before destroying it) introduced an error in the accounting
> of cpupools regarding the number of domains. The number of domains
> is nor adjusted when a domain is mo
On Wed, Nov 12, 2014 at 11:10 AM, Juergen Gross wrote:
> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> cpupool0 before destroying it) introduced an error in the accounting
> of cpupools regarding the number of domains. The number of domains
> is nor adjusted when a domain is mo
CCing the folks who signed-of-by is on the original patch
On Wed, 2014-11-12 at 11:05 +, Wei Liu wrote:
> The `if' statement considered return value 0 from libxl_domain_info an
> error, while 0 actually means success.
>
> Signed-off-by: Wei Liu
Acked-by: Ian Campbell
> Cc: Ian Jackson
>
You forgot to add the release manager... I've done that for you.
In <1413279117.1497.25.ca...@citrix.com> I said:
> Acked-by: Ian Campbell
>
> Is this a bug fix or a feature? What are the risks? IsLKonrad OK with
> it?
On Wed, 2014-11-12 at 12:06 +0100, Olaf Hering wrote:
> Ping?
>
>
> > ...
On 11/12/2014 12:10 PM, George Dunlap wrote:
On Wed, Nov 12, 2014 at 10:40 AM, Juergen Gross wrote:
Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
cpupool0 before destroying it) introduced an error in the accounting
of cpupools regarding the number of domains. The number of dom
On Tue, Nov 11, 2014 at 11:42:04AM -0500, Zhigang Wang wrote:
> On 11/11/2014 10:20 AM, Wei Liu wrote:
> > On Tue, Nov 11, 2014 at 09:41:32AM -0500, Zhigang Wang wrote:
> >> On 11/11/2014 06:01 AM, Wei Liu wrote:
> >>> On Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
> >>> [...]
>
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
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.
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
The feature has been removed from Xen. Also Linux cannot use it on ARM32
without CONFIG_ARM_LPAE.
Signed-off-by: Stefano Stabellini
Acked-by: Ian Campbell
Reviewed-by: David Vrabel
Reviewed-by: Catalin Marinas
---
Changes in v2:
- remove the definition of XENFEAT_grant_map_identity.
---
arc
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
Reviewed-by: Catalin Marinas
---
arch/arm64/include/asm/device.h |1 +
arch/arm64/
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
Reviewed-by: Catalin Marinas
CC: li...@arm.linux.org.uk
---
arch/arm/include/asm/device.h
Dom0 is not actually capable of issuing outer_inv_range or
outer_clean_range calls.
Signed-off-by: Stefano Stabellini
Acked-by: Ian Campbell
Reviewed-by: Catalin Marinas
---
arch/arm/xen/mm32.c |9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm
dev_addr is the machine address of the page.
The new parameter can be used by the ARM and ARM64 implementations of
xen_dma_map_page to find out if the page is a local page (pfn == mfn) or
a foreign page (pfn != mfn).
dev_addr could be retrieved again from the physical address, using
pfn_to_mfn, b
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
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
Merge xen/mm32.c into xen/mm.c.
As a consequence the code gets compiled on arm64 too.
Signed-off-by: Stefano Stabellini
Reviewed-by: Catalin Marinas
---
arch/arm/xen/Makefile |2 +-
arch/arm/xen/mm.c | 84 +
arch/arm/xe
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
Reviewed-by: Catalin Marinas
---
drivers/xen/swiotlb-xen.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/xen/
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
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:
On Tue, 2014-11-11 at 00:56 -0800, Steve Freitas wrote:
> configure: error: Unable to find Python development headers
> configure: error: ./configure failed for tools
config.log/status (perhaps the ones under tools/) might give a clue as
to why it thinks it can't find them.
Ian.
__
On Mon, 2014-11-10 at 10:38 -0500, Zhigang Wang wrote:
> 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 t
On Tue, Nov 11, 2014 at 06:03:22PM +, David Vrabel wrote:
> On 11/11/14 17:36, Wei Liu wrote:
> > # What's already implemented?
> >
> > PV vNUMA support in libxl/xl and Linux kernel.
>
> Linux doesn't have vnuma yet, although the last set of patches I saw
> looked fine and were waiting for ac
On 11/11/2014 08:28 PM, M A Young wrote:
> The build of xen-4.5.0-rc2 fails if XSM_ENABLE=y due to an inconsistency
> in commit fda1614 "xen/arm: Add support for GICv3 for domU" which uses
> XEN_DOMCTL_configure_domain in xen/xsm/flask/hooks.c and
> xen/xsm/flask/policy/access_vectors but XEN_DOMCT
On 11/12/2014 01:58 AM, Hu, Robert wrote:
2. Failed to hotplug a VT-d device with XEN4.5-RC1
http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
This should be addressed by these two:
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00875.html
http://lists.x
On Wed, 2014-11-12 at 10:53 +, Hu, Robert wrote:
> I think it shall be stored somewhere and be tracked, rather than one
> by one mail thread. To follow your suggestion, I would next time in
> addition send each bug per mail, with descriptions contained.
If you send each bug as a separate email
On Wed, Nov 12, 2014 at 09:35:01AM +, Jan Beulich wrote:
> >>> On 11.11.14 at 19:03, wrote:
> > On 11/11/14 17:36, Wei Liu wrote:
> >> Option #1 requires less modification to guest, because guest won't
> >> need to switch to new hypercall. It's unclear at this point if a guest
> >> asks to pop
flight 31497 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31497/
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-fre
>>> On 12.11.14 at 14:45, wrote:
> On Wed, Nov 12, 2014 at 09:35:01AM +, Jan Beulich wrote:
>> >>> On 11.11.14 at 19:03, wrote:
>> > On 11/11/14 17:36, Wei Liu wrote:
>> >> Option #1 requires less modification to guest, because guest won't
>> >> need to switch to new hypercall. It's unclear a
Hi,
On 11/12/2014 11:39 AM, Stefano Stabellini wrote:
> 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 b
On 11/12/2014 10:07 AM, Ian Campbell wrote:
> On Tue, 2014-11-11 at 17:50 +0100, Julien Grall wrote:
>> Hi,
>>
>> Somehow I missed this email.
>>
>> On 30/10/2014 13:33, Ian Campbell wrote:
>>> create !
>>> title it arm: domain 0 disables clocks which are in fact being used
>>> thanks
>>>
>>> On We
On Wed, Nov 12, 2014 at 02:13:09PM +, Jan Beulich wrote:
> >>> On 12.11.14 at 14:45, wrote:
> > On Wed, Nov 12, 2014 at 09:35:01AM +, Jan Beulich wrote:
> >> >>> On 11.11.14 at 19:03, wrote:
> >> > On 11/11/14 17:36, Wei Liu wrote:
> >> >> Option #1 requires less modification to guest, be
On 12/11/14 14:27, Wei Liu wrote:
> On Wed, Nov 12, 2014 at 02:13:09PM +, Jan Beulich wrote:
> On 12.11.14 at 14:45, wrote:
>>> On Wed, Nov 12, 2014 at 09:35:01AM +, Jan Beulich wrote:
>>> On 11.11.14 at 19:03, wrote:
> On 11/11/14 17:36, Wei Liu wrote:
>> Option #1 requir
On 11/12/2014 06:31 AM, Wei Liu wrote:
> On Tue, Nov 11, 2014 at 11:42:04AM -0500, Zhigang Wang wrote:
>> On 11/11/2014 10:20 AM, Wei Liu wrote:
>>> On Tue, Nov 11, 2014 at 09:41:32AM -0500, Zhigang Wang wrote:
On 11/11/2014 06:01 AM, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 12:54:18PM -05
On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> Also I want clarify one thing: the @introduceDomain watch is triggered at the
> same
> time for xm/xend and xl: when VM fully migrated.
>
> The different between xm/xend and xl is: xend will populate destination side
> VM
> xenstore entri
On Wed, Nov 12, 2014 at 02:29:56PM +, David Vrabel wrote:
> On 12/11/14 14:27, Wei Liu wrote:
> > On Wed, Nov 12, 2014 at 02:13:09PM +, Jan Beulich wrote:
> > On 12.11.14 at 14:45, wrote:
> >>> On Wed, Nov 12, 2014 at 09:35:01AM +, Jan Beulich wrote:
> >>> On 11.11.14 at 19:03,
On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
> On 11/12/2014 09:40 AM, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> >> Also I want clarify one thing: the @introduceDomain watch is triggered at
> >> the same
> >> time for xm/xend and xl: when VM fully m
On 11/12/2014 09:40 AM, Ian Campbell wrote:
> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
>> Also I want clarify one thing: the @introduceDomain watch is triggered at
>> the same
>> time for xm/xend and xl: when VM fully migrated.
>>
>> The different between xm/xend and xl is: xend will
>>> On 12.11.14 at 15:40, wrote:
> So what's the "usual technique" in Linux to make sure if a specific
> Xen feature is present?
>
> Jan, is it suitable to use a XENFEAT_* bit for this?
Yes, that would be the canonical way.
Jan
___
Xen-devel mailing
On 11/12/2014 09:52 AM, Ian Campbell wrote:
> On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
>> On 11/12/2014 09:40 AM, Ian Campbell wrote:
>>> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
Also I want clarify one thing: the @introduceDomain watch is triggered at
the sam
Signed-off-by: Clark Laughlin
---
tools/misc/mkdeb | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
index 3bbf881..4d14d9e 100644
--- a/tools/misc/mkdeb
+++ b/tools/misc/mkdeb
@@ -13,11 +13,16 @@ fi
cd $1
version=$2
-if t
ia64 provides a duplicate of the generic dma_get_required_mask()
because it has ARCH_HAS_GET_REQUIRED_MASK. Provide a common
dma_get_require_mask_max_pfn() instead.
Signed-off-by: David Vrabel
Cc: Tony Luck
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
---
arch/ia64/include/asm/machvec.h
On a Xen PV guest the DMA addresses and physical addresses are not 1:1
(such as Xen PV guests) and the generic dma_get_required_mask() does
not return the correct mask (since it uses max_pfn).
Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to
Use dma_ops->get_required_mask() if provided, defaulting to
dma_get_requried_mask_from_max_pfn().
This is needed on systems (such as Xen PV guests) where the DMA
address and the physical address are not equal.
Signed-off-by: David Vrabel
---
arch/x86/include/asm/device.h |2 ++
arch/x86/ker
On systems where DMA addresses and physical addresses are not 1:1
(such as Xen PV guests), the generic dma_get_required_mask() will not
return the correct mask (since it uses max_pfn).
Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow t
On Wed, 2014-11-12 at 09:27 -0600, Clark Laughlin wrote:
> Signed-off-by: Clark Laughlin
Acked-by: Ian Campbell
The mapping is a bit more zealous that strictly needed:
> +# map the architecture, if necessary
> +arch=$XEN_TARGET_ARCH
> +case "$XEN_TARGET_ARCH" in
> + x86_32) arch=i386 ;;
> +
The spin-lock implementation in the xen-access test program is implemented
in a fashion that is actually incomplete. The x86 assembly that guarantees that
the lock is held by only one thread lacks the "lock;" instruction.
However, the spin-lock is not actually necessary in xen-access as it is not
The name of the ring still implies it is used only for memory accesses,
which is no longer the case. It is also used to deliver variuos HVM events,
thus the name "monitor" is more appropriate in this setting.
Signed-off-by: Tamas K Lengyel
---
tools/libxc/xc_domain_restore.c | 14 +++---
This patch series aims to clean up the mem_event subsystem within Xen. The
original use-case for this system was to allow external helper applications
running in privileged domains to control various memory operations performed
by Xen. Amongs these were paging, sharing and access control. The subsy
The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This patch removes the dependency that mem_access nee
The only use-case of the mem_event_op structure had been in mem_paging,
thus renaming the structure mem_paging_op and relocating its associated
functions clarifies its actual usage.
Signed-off-by: Tamas K Lengyel
---
tools/libxc/xc_mem_event.c | 16
tools/libxc/xc_mem_pagi
From: Razvan Cojocaru
The public mem_event structures used to communicate with helper applications via
shared rings have been used in different settings. However, the variable names
within this structure have not reflected this fact, resulting in the reuse of
variables to mean different things un
The function names currently imply that these events are to be delivered via
the memory_event subsystem. However, the naming is confusing as these events
have nothing to do with actual memory events. Simply naming these functions
hvm_event_* more accurately describe their usage.
Signed-off-by: Tam
mkdeb previously set the package architecture to be 'amd64' for anything other
than
XEN_TARGET_ARCH=x86_32. This patch attempts to correctly map the architecture
from
GNU names to debian names for x86 and ARM architectures, or otherwise, defaults
it
to the value in XEN_TARGET_ARCH.
Signed-off-
On Wed, Nov 12, 2014 at 10:04:35AM -0500, Zhigang Wang wrote:
> On 11/12/2014 09:52 AM, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
> >> On 11/12/2014 09:40 AM, Ian Campbell wrote:
> >>> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> Also I want cla
On Wed, 2014-11-12 at 09:38 -0600, Clark Laughlin wrote:
> mkdeb previously set the package architecture to be 'amd64' for anything
> other than
> XEN_TARGET_ARCH=x86_32. This patch attempts to correctly map the
> architecture from
> GNU names to debian names for x86 and ARM architectures, or ot
This patch fixes two issues with persistent grants and the disk PV backend
(Qdisk):
- Don't use batch mappings when using persistent grants, doing so prevents
unmapping single grants (the whole area has to be unmapped at once).
- Unmap persistent grants before switching to the closed state, s
On 12/11/14 15:31, Tamas K Lengyel wrote:
> This patch series aims to clean up the mem_event subsystem within Xen. The
> original use-case for this system was to allow external helper applications
> running in privileged domains to control various memory operations performed
> by Xen. Amongs these
On Tue, Nov 4, 2014 at 1:45 PM, Andrew Cooper
wrote:
> On 04/11/14 18:42, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 04, 2014 at 06:07:19PM +, Andrew Cooper wrote:
> >> On 04/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> >>> On Tue, Nov 04, 2014 at 11:52:47AM +, Ian Campbell wrote:
>
1 - 100 of 160 matches
Mail list logo
