Hi,
I am aware that Xen via libvirt is in the group C support for openstack but
since I am not able to install xenserver iso at compute machines I have, I
have to consider to use xen with libvirt (xcp-xapi is not available for
ubuntu14.04). I have three nodes, each one running ubuntu 14.04. I foll
Hello,
for some time we observed several host where xenstored crashes. We
observed the following crash two times by now:
> #0 talloc_chunk_from_ptr (ptr=0xff00) at talloc.c:116
> 116 if ((tc->flags & ~0xF) != TALLOC_MAGIC) {
> warning: not using untrusted file
> "/root/xen-4
On 11/12/2014 11:12 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Nov 11, 2014 at 06:43:43AM +0100, Juergen Gross wrote:
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 mapp
On 11/12/2014 11:10 PM, Konrad Rzeszutek Wilk wrote:
@@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
unsigned long max_pfn;
unsigned long pfn;
-if (xen_feature(XENFEAT_auto_translated_physmap))
+ if (xen_feature(XENFEAT_auto_translated_phys
On 11/12/2014 10:45 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Nov 11, 2014 at 06:43:40AM +0100, Juergen Gross wrote:
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index a8a1a3d..d3e492b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1223,6 +1223,10 @@ static void __init xen_p
Now it's no need to set the "cpuid= " option in the config file
to expose the 1GB hugepage feature to guest.
Signed-off-by: Li Liang
---
tools/libxc/xc_cpuid_x86.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index a18b1ff..561c5b5 1
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 11/11/2014 at 04:07 PM, in message
<5462343c026600078...@soto.provo.novell.com>, "Chun Yan Liu"
wrote:
>
On 11/11/2014 at 01:04 AM, in message
> , George
> Dunlap wrote:
> > On Mon, Nov 10, 2014 at 8:17 AM, Chunyan Liu wrote:
> >
> > >
> > > 3. Function Implement
flight 31507 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31507/
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
> -Original Message-
> From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz]
> Sent: Wednesday, November 12, 2014 5:59 PM
> To: Hu, Robert; xen-devel@lists.xen.org
> Cc: jbeul...@suse.com
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
>
> Il 12/11/2014 07:58, Hu, Rober
Hi,
This is a separated report for bug
http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897
Environment:
Service Arch (ia32/ia32e/IA64): ia32e
Guest Arch (ia32/ia32e/IA64):
Guest OS Type (Linux/Windows):
Change Set: Xen4.5-RC1 (git:1b068a5b485062c862c20d8ba7674faa9
Hi,
This is a separated bug report for
http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896.
Environment:
Service Arch (ia32/ia32e/IA64): ia32e
Guest Arch (ia32/ia32e/IA64): ia32e
Guest OS Type (Linux/Windows): Windows8.1, Windows2012
Change Set: Xen4.5-RC1 (git:1b
flight 31508 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31508/
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
flight 31504 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31504/
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
build-i386
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Wednesday, November 12, 2014 7:07 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; jbeul...@suse.com; wei.l...@citrix.com
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
>
> On Wed, Nov 12, 2
On November 12, 2014 8:01:21 PM EST, Chao Peng
wrote:
>On Wed, Nov 12, 2014 at 10:22:07AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Wed, Nov 12, 2014 at 11:10:52AM +, Ian Campbell wrote:
>> > CCing the folks who signed-of-by is on the original patch
>> >
>> > On Wed, 2014-11-12 at 11:05 +000
On Wed, Nov 12, 2014 at 10:22:07AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 11:10:52AM +, Ian Campbell wrote:
> > 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
Hello,
I am trying to set up a shared page between the hypervisor and a Linux guest
kernel. In Xen I am doing:
void *ptr = alloc_xenheap_page();
share_xen_page_with_guest(virt_to_page(ptr), current->domain,
XENSHARE_writable);
unsigned int mfn = virt_to_mfn(ptr);
And my plan was to pass the mf
flight 31500 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31500/
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
On Wed, Nov 12, 2014 at 12:06:20PM -0400, Konrad Rzeszutek Wilk wrote:
> 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.
>
> Yeey! Thank you for doing those tests.
> >
> > Test environment:
> > Xen:
On Tue, Nov 11, 2014 at 06:43:44AM +0100, Juergen Gross wrote:
> 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
s/when/where/
> soon as the
On Tue, Nov 11, 2014 at 06:43:43AM +0100, Juergen Gross wrote:
> 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.
>
What is
> @@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
> unsigned long max_pfn;
> unsigned long pfn;
>
> - if (xen_feature(XENFEAT_auto_translated_physmap))
> + if (xen_feature(XENFEAT_auto_translated_physmap))
Spurious change.
.. snip..
> diff --git a/
flight 31509 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31509/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels
fail REGR. vs. 31437
tes
On Tue, Nov 11, 2014 at 06:43:40AM +0100, Juergen Gross wrote:
> 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 lo
On Wed, Nov 12, 2014 at 02:54:00PM -0500, Zhigang Wang wrote:
> On 11/12/2014 12:04 PM, Wei Liu wrote:
> > This small series change the behavior of
> > libxl_retrieve_domain_configuration,
> > to make it continue to retrieve information from xenstore even if JSON
> > template
> > is not available
On 11/12/2014 12:04 PM, Wei Liu wrote:
> This small series change the behavior of libxl_retrieve_domain_configuration,
> to make it continue to retrieve information from xenstore even if JSON
> template
> is not available.
>
> This change of API behaviour is only internal. Conceptually speaking,
On Wed, Nov 12, 2014 at 06:23:46PM +0100, Olaf Hering wrote:
> On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
>
> > On Wed, Nov 12, 2014 at 06:06:57PM +0100, Olaf Hering wrote:
> > > On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
> > >
> > >
> > > > What happens if we do not take that in now but de
flight 31505 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31505/
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
On Tue, Nov 11, 2014 at 10:29:32AM +, David Vrabel wrote:
> On 11/11/14 05:43, Juergen Gross wrote:
> > 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
On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson
wrote:
> 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
On Wed, 12 Nov 2014, Roger Pau Monne wrote:
> 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).
The real is
On Wed, Nov 12, 2014 at 05:31:33PM +, George Dunlap wrote:
> Return proper error codes on failure so that scripts can tell whether
> the command completed properly or not.
>
> Signed-off-by: George Dunlap
> ---
> CC: Ian Campbell
> CC: Ian Jackson
Acked-by: Wei Liu
> CC: Konrad Wilk
>
Return proper error codes on failure so that scripts can tell whether
the command completed properly or not.
Signed-off-by: George Dunlap
---
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
CC: Konrad Wilk
Release justification: This is a bug fix. It's a fairly minor one,
but it's also a very
Continue when libxl_retrieve_domain_configuration encounters
ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
configuration pulled from xenstore. In this case
ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
error happens along the way.
Signed-off-by: We
Unconditionally print out the partial configuration.
Signed-off-by: Wei Liu
Cc: Zhigang Wang
Cc: Ian Campbell
Cc: Ian Jackson
---
tools/libxl/xl_cmdimpl.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9
On Wed, Nov 12, 2014 at 10:22:07AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 11:10:52AM +, Ian Campbell wrote:
> > 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
On Wed, Nov 12, 2014 at 12:18:32PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 05:04:23PM +, Wei Liu wrote:
> > This small series change the behavior of
> > libxl_retrieve_domain_configuration,
> > to make it continue to retrieve information from xenstore even if JSON
> > te
>>> On 12.11.14 at 16:14, wrote:
> On Wed, Nov 12, 2014 at 10:01:28AM +, Malcolm Crossley wrote:
>> I agree with Jan. By using xl pci-attach you are effectively hotplugging
>> a PCI device (in the bare metal case). The only way this will work
>> reliably is if you reserve some MMIO space for t
On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 06:06:57PM +0100, Olaf Hering wrote:
> > On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
> >
> >
> > > What happens if we do not take that in now but delay to Xen 4.6?
> >
> > I will be very unhappy...
> > I mean, what exactly
On Wed, Nov 12, 2014 at 03:55:51PM +, George Dunlap wrote:
> On 11/12/2014 03:45 PM, Roger Pau Monne wrote:
> >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
> >unmapp
>>> On 12.11.14 at 17:59, wrote:
> On 12/11/14 15:55, Jan Beulich wrote:
> On 12.11.14 at 16:25, wrote:
>>> +u64
>>> +xen_swiotlb_get_required_mask(struct device *dev)
>>> +{
>>> + u64 max_mfn;
>>> +
>>> + max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>>> +
>>> + return
On Wed, Nov 12, 2014 at 05:04:23PM +, Wei Liu wrote:
> This small series change the behavior of libxl_retrieve_domain_configuration,
> to make it continue to retrieve information from xenstore even if JSON
> template
> is not available.
>
> This change of API behaviour is only internal. Conce
On Wed, Nov 12, 2014 at 06:06:57PM +0100, Olaf Hering wrote:
> On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
>
>
> > What happens if we do not take that in now but delay to Xen 4.6?
>
> I will be very unhappy...
> I mean, what exactly is the concern here?!
I need to know what the risk is if thi
This small series change the behavior of libxl_retrieve_domain_configuration,
to make it continue to retrieve information from xenstore even if JSON template
is not available.
This change of API behaviour is only internal. Conceptually speaking, any
non-zero return value means d_config is partiall
On Wed, Nov 12, 2014 at 09:23:58AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 12:14:48PM +, Wei Liu wrote:
> > 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
On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
> What happens if we do not take that in now but delay to Xen 4.6?
I will be very unhappy...
I mean, what exactly is the concern here?!
> Will systemd still correctly work? It looks like it will and
> this is just an improvement that makes the code
On Wed, Nov 12, 2014 at 10:01:28AM +, Malcolm Crossley wrote:
> 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 i
> Basic root-causing log:
> --
> [root@vt-hsw1 carl]# xl cr xlexample.hvm
> Parsing config from xlexample.hvm
> libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error
> message from QMP server: Unsupported bus. Bus doesn't have property
> 'acpi-pcihp-bsel' s
On 12/11/14 15:55, Jan Beulich wrote:
On 12.11.14 at 16:25, wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +u64 max_mfn;
>> +
>> +max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT)
On Wed, Nov 12, 2014 at 11:10:52AM +, Ian Campbell wrote:
> 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.
> >
On Wed, Nov 12, 2014 at 12:10:02PM +0100, 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 domai
On Wed, Nov 12, 2014 at 12:14:48PM +, Wei Liu wrote:
> 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, altho
On Wed, Nov 12, 2014 at 11:11:15AM +, George Dunlap wrote:
> 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
On Wed, Nov 12, 2014 at 10:56:24AM +, Ian Campbell wrote:
> 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
On Wed, Nov 12, 2014 at 11:12:06AM +, Ian Campbell wrote:
> 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, 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.
Yeey! Thank you for doing those tests.
>
> Test environment:
> Xen: Xen 4.5-rc1
> Dom0: Linux kernel 3.17.0
> Hardware: Intel IVT-EX, Haswell-EP, BDW Client
On 12/11/14 15:31, Tamas K Lengyel wrote:
> diff --git a/xen/include/public/mem_event.h b/xen/include/public/mem_event.h
> index 599f9e8..c0e9394 100644
> --- a/xen/include/public/mem_event.h
> +++ b/xen/include/public/mem_event.h
> @@ -49,15 +49,19 @@
> #define MEM_EVENT_FLAG_EMULATE_NOWRITE (1 <
On 11/12/2014 03:45 PM, Roger Pau Monne wrote:
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 persi
>>> On 12.11.14 at 16:25, wrote:
> +u64
> +xen_swiotlb_get_required_mask(struct device *dev)
> +{
> + u64 max_mfn;
> +
> + max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
> +
> + return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
> +}
The value the hypercall returns
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:
>
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
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 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
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
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-
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
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 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 +++---
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
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 ;;
> +
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
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 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
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
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
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
>>> 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: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 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 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: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 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 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 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 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
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 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
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 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
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 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 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 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 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, 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 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
1 - 100 of 160 matches
Mail list logo
