On Fri, Dec 05, Olaf Hering wrote:
> On Thu, Dec 04, Konrad Rzeszutek Wilk wrote:
>
> > On Thu, Dec 04, 2014 at 08:47:56AM +0100, Olaf Hering wrote:
> > > Is that something the sysadmin has to adjust, or should the xen source
> > > provide proper values?
> > It would be rather cumbersome if the s
On Fri, Dec 05, Olaf Hering wrote:
> So looking again at
> tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in it seems that it
> happens to work for me because XENSTORED_MOUNT_CTX is set within that
> file. So if something happens to need a different value for
> XENSTORED_MOUNT_CTX it has to b
>>> On 04.12.14 at 17:35, wrote:
> I've just stumbled upon this assert while testing PVH on different
> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
> and OUTS go through handle_mmio. So using this instructions from a PVH
> guest basically kills Xen.
>
> I've removed it a
>>> On 04.12.14 at 18:25, wrote:
> Potential feature flags, based on whiteboard notes at the session.
> Things that are 'Yes' in both columns might not need actual flags :)
>
> 'HVM' 'PVH'
> 64bit hypercalls Yes Yes
> 32bit hypercalls Yes No
I
Thanks Ian for helping me with the links,
FYI, I found following link :
https://blog.xenproject.org/2014/04/01/virtualization-on-arm-with-xen/
(Here it suggests using Foundation Model and Linaro, basically an emulator
to get started) though the advanced emulators offered by ARM are paid ones)
Wou
Please don't top post.
On Fri, 2014-12-05 at 14:51 +0530, Sagun Garg wrote:
> Thanks Ian for helping me with the links,
>
>
> FYI, I found following link :
> https://blog.xenproject.org/2014/04/01/virtualization-on-arm-with-xen/
> (Here it suggests using Foundation Model and Linaro, basically an
On Fri, 2014-12-05 at 07:37 +, Jan Beulich wrote:
> >>> On 04.12.14 at 22:22, wrote:
> > On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich wrote:
> > On 03.12.14 at 22:02, wrote:
> >>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
> >>>xen/arch/*/efi/efi-boot.c? efi-boot.h contains
The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
currently contains the mfn of the top level page frame of the 3 level
p2m tree, which is used by the Xen tools during saving and restoring
(and live migration) of pv domains and for crash dump analysis. With
three levels of the p2m tr
The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
currently contains the mfn of the top level page frame of the 3 level
p2m tree, which is used by the Xen tools during saving and restoring
(and live migration) of pv domains and for crash dump analysis. With
three levels of the p2m tr
flight 32086 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32086/
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
Hi,
At 10:00 +0800 on 05 Dec (1417770044), Yu, Zhang wrote:
> >> @@ -5978,7 +5982,8 @@ long do_hvm_op(unsigned long op,
> >> XEN_GUEST_HANDLE_PARAM(void) arg)
> >> goto param_fail4;
> >> }
> >> if ( !p2m_is_ram(t) &&
> >> - (!p2m_is_ho
>>> On 03.12.14 at 17:04, wrote:
> The default limit for the number of PIRQs for hardware domains (dom0)
> is not sufficient for some (x86) systems.
>
> Since the pirq structures are individually and dynamically allocated,
> the limit for hardware domains may be increased to the number of
> possi
>>> On 05.12.14 at 10:33, wrote:
> On Fri, 2014-12-05 at 07:37 +, Jan Beulich wrote:
>> >>> On 04.12.14 at 22:22, wrote:
>> > On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich wrote:
>> > On 03.12.14 at 22:02, wrote:
>> >>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
>> >>>xen/ar
At 09:20 + on 05 Dec (1417767654), Jan Beulich wrote:
> >>> On 04.12.14 at 18:25, wrote:
> > Potential feature flags, based on whiteboard notes at the session.
> > Things that are 'Yes' in both columns might not need actual flags :)
> >
> > 'HVM' 'PVH'
> > 64bit hyp
On Thu, 2014-12-04 at 18:24 +, xen.org wrote:
> flight 32083 libvirt real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32083/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386-libvirt5 libvirt
On Tue, Dec 02, Wei Liu wrote:
> AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> incorrect, even in the event systemd library is available. Use
> PKG_CHECK_MODULES instead.
>
> Tested on Debian Jessie and Arch Linux.
I just tested this and got this failure. The reason is
On Fri, 2014-12-05 at 09:47 +, Jan Beulich wrote:
> >>> On 05.12.14 at 10:33, wrote:
> > On Fri, 2014-12-05 at 07:37 +, Jan Beulich wrote:
> >> >>> On 04.12.14 at 22:22, wrote:
> >> > On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich wrote:
> >> > On 03.12.14 at 22:02, wrote:
> >> >>> 3)
On Fri, 2014-12-05 at 10:49 +0100, Tim Deegan wrote:
> At 09:20 + on 05 Dec (1417767654), Jan Beulich wrote:
> > >>> On 04.12.14 at 18:25, wrote:
> > > Potential feature flags, based on whiteboard notes at the session.
> > > Things that are 'Yes' in both columns might not need actual flags :)
On Fri, 2014-12-05 at 10:51 +0100, Olaf Hering wrote:
> On Tue, Dec 02, Wei Liu wrote:
>
> > AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> > incorrect, even in the event systemd library is available. Use
> > PKG_CHECK_MODULES instead.
> >
> > Tested on Debian Jessie and
Hey folks,
In recent months I've been working on speed up the 'xl des' time of XEN
guest with large RAM, but there is still no good solution yet.
I'm looking forward to get more suggestions and appreciate for all of
your input.
(1) The problem
When 'xl destory' a guest with large memory, we have
On Fri, Dec 05, Ian Campbell wrote:
> On Fri, 2014-12-05 at 10:51 +0100, Olaf Hering wrote:
> > On Tue, Dec 02, Wei Liu wrote:
> >
> > > AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> > > incorrect, even in the event systemd library is available. Use
> > > PKG_CHECK_MODU
On 05/12/14 09:44, Jan Beulich wrote:
On 03.12.14 at 17:04, wrote:
>> The default limit for the number of PIRQs for hardware domains (dom0)
>> is not sufficient for some (x86) systems.
>>
>> Since the pirq structures are individually and dynamically allocated,
>> the limit for hardware domain
On 05/12/14 09:35, Juergen Gross wrote:
> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
> currently contains the mfn of the top level page frame of the 3 level
> p2m tree, which is used by the Xen tools during saving and restoring
> (and live migration) of pv domains and for cras
On 04/12/14 15:39, Alex Williamson wrote:
>
> I don't know what workaround you're talking about. As devices are
> released from the user, vfio-pci attempts to reset them. If
> pci_reset_function() returns success we mark the device clean, otherwise
> it gets marked dirty. Each time a device is
On 05/12/14 06:16, Juergen Gross wrote:
> The patch "Speed up set_phys_to_machine() by using read-only mappings"
> introduced a sparse warning:
>
> arch/x86/xen/p2m.c:628:13: sparse: incorrect type in argument 1
>(different address spaces)
>
> Avoid the warning.
Thank
On 05/12/14 09:54, Ian Campbell wrote:
> On Fri, 2014-12-05 at 10:49 +0100, Tim Deegan wrote:
>> At 09:20 + on 05 Dec (1417767654), Jan Beulich wrote:
>> On 04.12.14 at 18:25, wrote:
Potential feature flags, based on whiteboard notes at the session.
Things that are 'Yes' in both
Wei Liu writes:
> (I've skipped the internal implementation since I don't know what's
> required to fulfil soft reset.)
>
> On Wed, Dec 03, 2014 at 06:16:20PM +0100, Vitaly Kuznetsov wrote:
> [...]
>> + libxl__domain_create_state *dcs);
>>
>> /* Each ti
Linking fails with undefined reference to the used systemd functions.
Move LDFLAGS after the object files to fix the failure.
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xenstore/Makefile | 10 +-
1 file changed, 5 insertio
Hi Vijay,
On 05/12/2014 00:46, Vijay Kilari wrote:
> Yes, this is the behaviour that Iam seeing. In Linux, uart driver
masks TXI interrupt
in IMSC if buffer is empty. However in xen, this scenario is not
handled. This is the reason why cpu does not come out of uart irq
routine if TX interrupt i
Hi Konrad,
On 04/12/2014 19:34, Konrad Rzeszutek Wilk wrote:
On Thu, Dec 04, 2014 at 07:26:55PM +, Julien Grall wrote:
A 0 was forgotten when the arm32 BUG instruction opcode has been added in commit
3e802c6ca1fb9a9549258c2855a57cad483f3cbd "xen/arm: Correctly support WARN_ON".
This will r
On Fri, 2014-12-05 at 11:49 +0100, Olaf Hering wrote:
> Linking fails with undefined reference to the used systemd functions.
> Move LDFLAGS after the object files to fix the failure.
>
> Signed-off-by: Olaf Hering
> Cc: Ian Jackson
> Cc: Stefano Stabellini
Acked-by: Ian Campbell
This should
On Thu, 2014-12-04 at 14:34 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 04, 2014 at 07:26:55PM +, Julien Grall wrote:
> > A 0 was forgotten when the arm32 BUG instruction opcode has been added in
> > commit
> > 3e802c6ca1fb9a9549258c2855a57cad483f3cbd "xen/arm: Correctly support
> > WAR
On 04/12/14 17:25, Tim Deegan wrote:
> 'HVM' 'PVH'
> 64bit hypercalls Yes Yes
> 32bit hypercalls Yes No
> Paging assistance Yes Yes
> ioreq-servers Yes No
Perhaps, but no default on
El 05/12/14 a les 10.15, Jan Beulich ha escrit:
On 04.12.14 at 17:35, wrote:
>> I've just stumbled upon this assert while testing PVH on different
>> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
>> and OUTS go through handle_mmio. So using this instructions from a PVH
Hello,
On 05/12/2014 09:32, Ian Campbell wrote:
On Fri, 2014-12-05 at 14:51 +0530, Sagun Garg wrote:
Not sure what sorts of risks you mean, I don't think there is anything
Xen specific here, just the usual stuff with running an untested OS on
any new platform.
I don't know if Nexus devices are
On 05/12/14 11:07, Roger Pau Monné wrote:
> El 05/12/14 a les 10.15, Jan Beulich ha escrit:
> On 04.12.14 at 17:35, wrote:
>>> I've just stumbled upon this assert while testing PVH on different
>>> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
>>> and OUTS go through ha
>>> On 05.12.14 at 12:07, wrote:
> El 05/12/14 a les 10.15, Jan Beulich ha escrit:
> On 04.12.14 at 17:35, wrote:
>>> I've just stumbled upon this assert while testing PVH on different
>>> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
>>> and OUTS go through handle_mmi
Andrew validly points out that even if these masks aren't a formal part
of the hypercall interface, we aren't free to change them: A guest
suspended for migration in the middle of a continuation would fail to
work if resumed on a hypervisor using a different value. Hence add
respective comments to
On 05/12/14 09:44, Jan Beulich wrote:
On 03.12.14 at 17:04, wrote:
>> The default limit for the number of PIRQs for hardware domains (dom0)
>> is not sufficient for some (x86) systems.
>>
>> Since the pirq structures are individually and dynamically allocated,
>> the limit for hardware domain
Konrad and Michael Young reported SELinux related failures in
var-lib-xenstored.mount. The first patch tries to address this by
makeing it easier to change the value of XENSTORED_MOUNT_CTX.
Its not clear to me if the mount option "context=" should be
adjustable by configure --with-selinux-mount-co
On a non-SELinux system the mount option "context=none" works fine. But
with SELinux enabled a proper value has to be defined. To simplify the
required adjustment move XENSTORED_MOUNT_CTX from the service file to
the sysconfig file.
There is no need to require the creation of a new sysconfig file,
There is no need to require the creation of a new sysconfig file to
pass options to xenconsoled in the systemd service file. Reuse the
existing xencommons file. This file already contains the variable
XENCONSOLED_TRACE, which is used in the sysv runlevel script.
- Adjust systemd service file to us
The sysv runlevel script handles the boolean variable XENSTORED_TRACE
from sysconfig.xencommons to enable tracing. Recognize this also to
the systemd service file.
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/hotplug/Linux/systemd/x
The references Environment file does not exist, and the service file
does not make use of variables anyway.
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
1 file chang
There is no need to export XENSTORED_ROOTDIR. This variable can be
enabled in sysconfig/xencommons. If the variable is unset xenstored
will automatically use @XEN_LIB_STORED@.
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/hotplug/Lin
>>> On 04.12.14 at 18:01, wrote:
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -120,9 +120,120 @@ struct xmem_pool {
> char name[MAX_POOL_NAME_LEN];
> };
>
> +static struct xmem_pool *xenpool;
> +
> +static inline void MAPPING_INSERT(unsigned long r, int *fl, int
>>> On 05.12.14 at 13:02, wrote:
> On 05/12/14 09:44, Jan Beulich wrote:
> On 03.12.14 at 17:04, wrote:
>>> The default limit for the number of PIRQs for hardware domains (dom0)
>>> is not sufficient for some (x86) systems.
>>>
>>> Since the pirq structures are individually and dynamically al
Olaf Hering writes ("[PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to
sysconfig.xencommons"):
> On a non-SELinux system the mount option "context=none" works fine. But
> with SELinux enabled a proper value has to be defined. To simplify the
> required adjustment move XENSTORED_MOUNT_CTX from
Olaf Hering writes ("[PATCH 4/5] tools/hotplug: remove XENSTORED_ROOTDIR from
service file"):
> There is no need to export XENSTORED_ROOTDIR. This variable can be
> enabled in sysconfig/xencommons. If the variable is unset xenstored
> will automatically use @XEN_LIB_STORED@.
Acked-by: Ian Jackson
>>> On 05.12.14 at 11:00, wrote:
> 5. Potential workaround
> 5.1 Use per-cpu list in idle_loop()
> Delist a batch of pages from heap_list to a per-cpu list, then scrub the
> per-cpu list and free back to heap_list.
>
> But Jan disagree with this solution:
> "You should really drop the idea of rem
Olaf Hering writes ("[PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in
systemd"):
> The sysv runlevel script handles the boolean variable XENSTORED_TRACE
> from sysconfig.xencommons to enable tracing. Recognize this also to
> the systemd service file.
...
> -ExecStart=/bin/sh -c "exec $XENSTOR
On Fri, Dec 05, Ian Jackson wrote:
> Olaf Hering writes ("[PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to
> sysconfig.xencommons"):
> > On a non-SELinux system the mount option "context=none" works fine. But
> > with SELinux enabled a proper value has to be defined. To simplify the
> > req
Introduce two helper functions to savely read and write unsigned long
values from or to memory without crashing the system in case of access
failures.
These helpers can be used instead of open coded uses of __get_user()
and __put_user() avoiding the need to do casts to fix sparse warnings.
Use th
On Fri, Dec 05, Ian Jackson wrote:
> I think the only way to make this work properly is to factor the
> necessary parts out of init.d/xencommons into a new script which can
> be used by both xencommons and systemd. I'm not sure such a patch
> would be appropriate for 4.5 at this stage.
Yes, a he
On Fri, Dec 05, Olaf Hering wrote:
> On Fri, Dec 05, Ian Jackson wrote:
> > And won't this break existing systems which have an
> > /etc/{default,sysconfig}/xenstored ?
> Which systems would that be? That file is new in 4.5.
... Not the file itself but the usage of a to-be-created file ...
Olaf
On Fri, Dec 05, 2014 at 01:17:16AM +, Zhangleiqiang (Trump) wrote:
[...]
> > I think that's expected, because guest RX data path still uses grant_copy
> > while
> > guest TX uses grant_map to do zero-copy transmit.
>
> As far as I know, there are three main grant-related operations used in sp
Olaf Hering writes ("Re: [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to
sysconfig.xencommons"):
> On Fri, Dec 05, Ian Jackson wrote:
> > This patch looks like just the hook. It seems to be missing the part
> > where the actual selinux context is defined and plumbed through.
>
> The conte
Hi,
Maybe I'm misreading it, but it seems to me that netfront doesn't slice
up the linear buffer at all, just blindly sends it. In xennet_start_xmit:
unsigned int offset = offset_in_page(data);
unsigned int len = skb_headlen(skb);
...
tx->offset = offset;
tx->size = len;
Although in the slot
Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in
systemd"):
> On Fri, Dec 05, Ian Jackson wrote:
> > I think the only way to make this work properly is to factor the
> > necessary parts out of init.d/xencommons into a new script which can
> > be used by both xencommon
On Fri, Dec 05, Ian Jackson wrote:
> Olaf Hering writes ("Re: [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
> to sysconfig.xencommons"):
> > On Fri, Dec 05, Ian Jackson wrote:
> > > This patch looks like just the hook. It seems to be missing the part
> > > where the actual selinux context
On Fri, Dec 05, Ian Jackson wrote:
> Can systemd not launch these daemons by running the existing
> xencommons et al init scripts ? Obviously that won't give you all of
> systemd's shiny features but IMO it ought to work.
I think the point was to let systemd pass the file descriptors. Thats why
UART is not able to receive bytes when idle mode is not
configured properly. When we use Xen with old Linux
Kernel (for example 3.8) this kernel configures UART
idle mode even if the UART node in device tree is absent.
So UART works normally in this case. But new Linux
Kernel (3.12 and upper) doesn
The current value of nr_static_irqs + 256 is often too small for larger
systems. Make it dependent on CPU count and number of IO-APIC pins on
x86, and (until it obtains PCI support) simply NR_IRQS on ARM.
Signed-off-by: Jan Beulich
---
This is meant to be an alternative proposal to David's:
http:
On Tue, 2014-12-02 at 23:14 -0700, Chun Yan Liu wrote:
>
> >>> On 11/28/2014 at 11:43 PM, in message
> >>> <1417189409.23604.62.ca...@citrix.com>,
> Ian Campbell wrote:
> > On Tue, 2014-11-25 at 02:08 -0700, Chun Yan Liu wrote:
> > > Hi, Ian,
> > >
> > > According to previous discussion, sn
PVH guests are not supposed to access I/O ports they weren't given
access to (there's nothing to handle emulation of such accesses).
Reported-by: Roger Pau Monné
Signed-off-by: Jan Beulich
---
Note: Only compile tested so far.
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@
A generic dma_get_required_mask() is useful even for architectures (such
as ia64) that define ARCH_HAS_GET_REQUIRED_MASK.
Signed-off-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
drivers/base/platform.c | 10 --
include/linux/dma-mapping.h |1 +
2 files changed, 9 inser
Signed-off-by: David Vrabel
Reviewed-by: Stefano Stabellini
Cc: Tony Luck
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
---
arch/ia64/include/asm/machvec.h |2 +-
arch/ia64/include/asm/machvec_init.h |1 -
arch/ia64/pci/pci.c | 20
3 files c
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.
ARCH_HAS_DMA_GET_REQUIRED_MASK is defined in asm/device.h instead of
asm/dma-mapping.h
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 05/12/14 12:48, Zoltan Kiss wrote:
> Hi,
>
> Maybe I'm misreading it, but it seems to me that netfront doesn't slice
> up the linear buffer at all, just blindly sends it. In xennet_start_xmit:
This is handled in the beginning of xennet_make_frags() (which I would
agree isn't not the obvious pl
Hi Oleksandr,
On 05/12/14 13:46, Oleksandr Dmytryshyn wrote:
> UART is not able to receive bytes when idle mode is not
> configured properly. When we use Xen with old Linux
> Kernel (for example 3.8) this kernel configures UART
> idle mode even if the UART node in device tree is absent.
I don't u
On Fri, 2014-12-05 at 13:51 +, Jan Beulich wrote:
> #define nr_static_irqs NR_IRQS
> +#define arch_hwdom_irqs(domid) NR_IRQS
FWIW gic_number_lines() is the ARM equivalent of getting the number of
GSIs.
*BUT* we don't actually use pirqs on ARM (everything goes via the
virtualised interrupt co
On 05/12/14 11:31, Jan Beulich wrote:
> Andrew validly points out that even if these masks aren't a formal part
> of the hypercall interface, we aren't free to change them: A guest
> suspended for migration in the middle of a continuation would fail to
> work if resumed on a hypervisor using a diff
Hi,
On 05/12/14 14:27, Ian Campbell wrote:
> On Fri, 2014-12-05 at 13:51 +, Jan Beulich wrote:
>> #define nr_static_irqs NR_IRQS
>> +#define arch_hwdom_irqs(domid) NR_IRQS
>
> FWIW gic_number_lines() is the ARM equivalent of getting the number of
> GSIs.
>
> *BUT* we don't actually use pirq
On Fri, 2014-12-05 at 14:36 +, Julien Grall wrote:
> Hi,
>
> On 05/12/14 14:27, Ian Campbell wrote:
> > On Fri, 2014-12-05 at 13:51 +, Jan Beulich wrote:
> >> #define nr_static_irqs NR_IRQS
> >> +#define arch_hwdom_irqs(domid) NR_IRQS
> >
> > FWIW gic_number_lines() is the ARM equivalent
>>> On 05.12.14 at 15:36, wrote:
> On 05/12/14 11:31, Jan Beulich wrote:
>> Andrew validly points out that even if these masks aren't a formal part
>> of the hypercall interface, we aren't free to change them: A guest
>> suspended for migration in the middle of a continuation would fail to
>> work
>>> On 05.12.14 at 15:27, wrote:
> On Fri, 2014-12-05 at 13:51 +, Jan Beulich wrote:
>> #define nr_static_irqs NR_IRQS
>> +#define arch_hwdom_irqs(domid) NR_IRQS
>
> FWIW gic_number_lines() is the ARM equivalent of getting the number of
> GSIs.
>
> *BUT* we don't actually use pirqs on ARM (
On 05/12/14 13:51, Jan Beulich wrote:
> The current value of nr_static_irqs + 256 is often too small for larger
> systems. Make it dependent on CPU count and number of IO-APIC pins on
> x86, and (until it obtains PCI support) simply NR_IRQS on ARM.
>
> Signed-off-by: Jan Beulich
I obviously pref
On Fri, 2014-12-05 at 14:48 +, Jan Beulich wrote:
> >>> On 05.12.14 at 15:27, wrote:
> > On Fri, 2014-12-05 at 13:51 +, Jan Beulich wrote:
> >> #define nr_static_irqs NR_IRQS
> >> +#define arch_hwdom_irqs(domid) NR_IRQS
> >
> > FWIW gic_number_lines() is the ARM equivalent of getting the
On Thu, Dec 04, 2014 at 09:35:01AM +, Jan Beulich wrote:
> >>> On 03.12.14 at 22:02, wrote:
> > Hey,
> >
> > 1) Why is there in EFI code so many functions (e.g. efi_start(),
> >efi_arch_edd(), ...) with local variables declared as a static?
> >Though some of them have also regular loca
On Thu, Dec 04, 2014 at 01:25:55PM +, Ian Campbell wrote:
> On Tue, 2014-12-02 at 16:16 +0100, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper
>
> .gitignore updates seem harmless enough. so I've applied this and the
> third patch. Awaiting Konrad's verdict on the first.
Thanks!
Daniel
On Thu, Dec 04, 2014 at 09:53:40PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> > > Signed-off-by: Daniel Kiper
> >
> > This usage scenario which I can see this being
>>> On 05.12.14 at 15:48, wrote:
> On 05/12/14 13:51, Jan Beulich wrote:
>> +d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs +
>> extra_hwdom_irqs
>> + : arch_hwdom_irqs(domid);
>
> This means if the user asks for 0 extra (by the command line
Required by latest libvirt, to build docs.
Signed-off-by: Ian Campbell
---
ts-xen-build-prep | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 05a7857..a7d0d03 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -177,7 +177,7 @@
>>> On 05.12.14 at 15:51, wrote:
> On Thu, Dec 04, 2014 at 09:35:01AM +, Jan Beulich wrote:
>> >>> On 03.12.14 at 22:02, wrote:
>> > 3) Should not we change xen/arch/*/efi/efi-boot.h to
>> >xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
>> >code than definitions, declarations and
On 05/12/14 14:47, Jan Beulich wrote:
On 05.12.14 at 15:36, wrote:
>> On 05/12/14 11:31, Jan Beulich wrote:
>>> Andrew validly points out that even if these masks aren't a formal part
>>> of the hypercall interface, we aren't free to change them: A guest
>>> suspended for migration in the mid
Olaf Hering writes ("Re: [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to
sysconfig.xencommons"):
> On Fri, Dec 05, Ian Jackson wrote:
> > I confess I don't know very much about selinux, but shouldn't we be
> > providing a reasonable default policy, rather than leaving it to the
> > distro o
Konrad,
having been surprised to find your cpio scanning code to not work I
had to realize that this can't possibly work when the initrd is
compressed. Considering that you found this useful nevertheless -
am I to imply that you're running with (and only considering) non-
compressed initrd? Are th
flight 32089 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32089/
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. 31811
Tests which did n
>>> On 05.12.14 at 16:05, wrote:
> having been surprised to find your cpio scanning code to not work I
> had to realize that this can't possibly work when the initrd is
> compressed. Considering that you found this useful nevertheless -
> am I to imply that you're running with (and only considerin
>>> On 05.12.14 at 16:01, wrote:
> On 05/12/14 14:47, Jan Beulich wrote:
> On 05.12.14 at 15:36, wrote:
>>> On 05/12/14 11:31, Jan Beulich wrote:
Andrew validly points out that even if these masks aren't a formal part
of the hypercall interface, we aren't free to change them: A gues
On 05/12/14 12:42, Wei Liu wrote:
On Fri, Dec 05, 2014 at 01:17:16AM +, Zhangleiqiang (Trump) wrote:
[...]
I think that's expected, because guest RX data path still uses grant_copy while
guest TX uses grant_map to do zero-copy transmit.
As far as I know, there are three main grant-relate
On 04/12/14 14:31, Zhangleiqiang (Trump) wrote:
-Original Message-
From: Zoltan Kiss [mailto:zoltan.k...@linaro.org]
Sent: Thursday, December 04, 2014 9:35 PM
To: Zhangleiqiang (Trump); Wei Liu; xen-devel@lists.xen.org
Cc: Xiaoding (B); Zhuangyuxin; zhangleiqiang; Luohao (brian); Yuzhou
On 05/12/14 14:42, Ian Campbell wrote:
> On Fri, 2014-12-05 at 14:36 +, Julien Grall wrote:
>> Hi,
>>
>> On 05/12/14 14:27, Ian Campbell wrote:
>>> On Fri, 2014-12-05 at 13:51 +, Jan Beulich wrote:
#define nr_static_irqs NR_IRQS
+#define arch_hwdom_irqs(domid) NR_IRQS
>>>
>>> FWI
On 05/12/14 15:18, Jan Beulich wrote:
On 05.12.14 at 16:01, wrote:
>> On 05/12/14 14:47, Jan Beulich wrote:
>> On 05.12.14 at 15:36, wrote:
On 05/12/14 11:31, Jan Beulich wrote:
> Andrew validly points out that even if these masks aren't a formal part
> of the hypercall inte
xen.org writes ("[xen-4.4-testing test] 31991: regressions - FAIL"):
> flight 31991 xen-4.4-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31991/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i
On Fri, Dec 05, 2014 at 01:05:48PM +0100, Olaf Hering wrote:
> On a non-SELinux system the mount option "context=none" works fine.
That's not true. I've tested 'context=none' on ArchLinux which have no
support (or limited) for selinux, and the option give this error:
"tmpfs: Bad mount option conte
On Thu, Dec 04, 2014 at 10:12:18AM +, xen.org wrote:
> flight 32051 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32051/
>
> Regressions :-(
There does not seem to be anything warranting that.
The failure is that this:
07 Z executing ssh ... osstest@10.80.250.
>>> On 05.12.14 at 16:25, wrote:
> - XEN_DOMCTL_irq_permission => I don't really understand this bits.
> AFAIU the pirq number is different on each domain. But we use it to
> check permission on both domain. Shouldn't we translate the pirq to irq
> for the current->domain?
Indeed, see also
1 - 100 of 154 matches
Mail list logo
