flight 32102 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32102/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 32005
build-amd64-libvirt
XenGT (Intel Graphics Virtualization technology, please refer to
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-
xengt) driver runs inside Dom0 as a virtual graphics device model,
and needs to trap and emulate the guest's write operations to some
specific memory pages, like memory p
From: Yu Zhang
A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's page tables. Handling of this new
p2m type are similar with existing p2m_ram_ro in most condition
checks, with only difference on final policy of emulation vs. drop.
For p2m_ram_ro types,
From: Yu Zhang
Currently, the P2M_RO_TYPES bears 2 meanings: one is
"_PAGE_RW bit is clear in their PTEs", and another is
to discard the write operations on these pages. This
patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
to bear the second meaning, so we can use this type
class instead of
On Fri, 05 Dec 2014 14:06:53 +
"Jan Beulich" wrote:
> 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
From: Vijaya Kumar K
On pl011.c when TX interrupt is received and
TX buffer is empty, TX interrupt is not disabled and
hence UART interrupt routine see TX interrupt always
in MIS register and cpu loops infinitly.
With this patch, mask and umask TX interrupt
when required
Signed-off-by: Vijaya K
flight 32096 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32096/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32029
Tests which did not succeed,
While I am not a developer myself (I always sucked hard when it comes to read
and write code), there are several capabilities of Xen and its supporting
Software which I'm always interesed in how they progress, more out of curiosity
than anything else. However, usually, documentation seems to bac
Hi Jan,
On 05/12/2014 16:55, Jan Beulich wrote:
> I didn't change ARM, as I wasn't sure how far ahead this call could be
pulled.
AFAIU, the new function only requires that the page table are setup
(because of the alloc_xenheap_pages).
So console_init_mem could be called right after console
Hi,
I am trying to find a tutorial to jumpstart installing XenServer / XCP
on an ARM 64bit platform.
Could the mailing list help.
-Regards
Manish
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Feature patchsets that did not make it in by today have been put
on the deferred list.
Xen 4.5-rc3 was out on Wednesday (3rd). There are two known issues - with one
already in the tree (so will show up in RC4).
(see 'Known Issues' below) which are to be fixed by RC4 - if:
- The maintainers are f
On Fri, Dec 05, 2014 at 02:08:00PM +, David Vrabel wrote:
> 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 | 1
flight 32095 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32095/
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. 31781
Tests which are f
On Fri, Dec 05, 2014 at 02:07:59PM +, David Vrabel wrote:
> 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, mpt2
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 32093 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32093/
Regressions :-(
T
Not really familiar with libvirt, but...
On Fri, 5 Dec 2014 16:30:06 +
Anthony PERARD wrote:
> The path to the pty of a Xen PV console is set only in
> virDomainOpenConsole. But this is done too late. A call to
> virDomainGetXMLDesc done before OpenConsole will not have the path to
> the pty
po...@iki.fi said:
> I wonder if work is minimized if we attempt to merge before or after
> we (I?) take the carving knife for a second round in the rumprun-xen
> repo to minimize MiniOS to run only on top of itself.
Before, I think. Minimizing our copy of Mini-OS duplicates what we would
need to
On Fri, Dec 05, 2014 at 03:20:55PM +, Zoltan Kiss wrote:
>
>
> 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@l
andrew.coop...@citrix.com said:
> I think this is a very good idea, and I am completely in favour of it.
>
> There are already-identified issues such as MiniOS leaking things like
> ARRAY_SIZE() into linked namespaces, which I havn't yet had enough tuits
> to fix.
>
> I think splitting things lik
On 12/02/2014 11:13 AM, Thanos Makatos wrote:
This patch introduces the interface to allow user-space applications
execute grant-copy operations. This is done by sending an ioctl to the
grant device.
Signed-off-by: Thanos Makatos
---
drivers/xen/gntdev.c | 171 ++
On Fri, Dec 05, 2014 at 05:00:52PM +, Jan Beulich wrote:
> >>> On 05.12.14 at 17:40, wrote:
> > On Fri, Dec 05, 2014 at 03:00:14PM +, Jan Beulich wrote:
> >> but I don't think this possibility of renaming warrants a much longer
> >> discussion. Please also remember that renaming always imp
On Tue, Dec 02, Olaf Hering wrote:
> On Tue, Dec 02, Ian Campbell wrote:
>
> > On Mon, 2014-12-01 at 23:41 +, Mark Pryor wrote:
> > > list,
> >
> > Thanks. If you've identified a buggy changeset then it is fine to post
> > to the devel lists. I've added a CC. I've also CCd everyone listed in
On Fri, Dec 05, 2014 at 04:55:24PM +, Jan Beulich wrote:
> ... when "conring_size=" was specified on the command line. We can't
> really do this as early as we would want to when the option was not
> specified, as the default depends on knowing the system CPU count. Yet
> the parsing of the ACP
On Fri, Dec 05, 2014 at 10:30:01AM +, David Vrabel wrote:
> 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
On Fri, Dec 05, 2014 at 10:53:03AM +, Ian Campbell wrote:
> 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: Ia
On 12/05/2014 11:03 AM, Jan Beulich wrote:
On 05.12.14 at 16:55, wrote:
On 02.12.14 at 22:34, wrote:
+struct xen_sysctl_iotopo {
+uint16_t seg;
+uint8_t bus;
+uint8_t devfn;
+uint32_t node;
+};
This is PCI-centric without expressing in the name or layout.
xen_sysctl_pcitopo
The example XSM policy was missing permission for dom0_t to migrate
domains; add these permissions.
Reported-by: Wei Liu
Signed-off-by: Daniel De Graaf
---
This has been tested with xl save/restore on a PV domain, which now
succeeds without producing AVC denials.
tools/flask/policy/policy/mod
On 12/05/2014 10:53 AM, Jan Beulich wrote:
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -56,6 +56,8 @@ struct pci_dev {
u8 phantom_stride;
+int node; /* NUMA node */
I don't think we currently support node IDs wider than 8 bits.
I used an int because pxm_to_nod
>>> On 05.12.14 at 17:40, wrote:
> On Fri, Dec 05, 2014 at 03:00:14PM +, Jan Beulich wrote:
>> but I don't think this possibility of renaming warrants a much longer
>> discussion. Please also remember that renaming always implies more
>> cumbersome backporting, even if only slightly more.
>
>
... when "conring_size=" was specified on the command line. We can't
really do this as early as we would want to when the option was not
specified, as the default depends on knowing the system CPU count. Yet
the parsing of the ACPI tables is one of the things that generates a
lot of output especial
On Fri, Dec 05, 2014 at 04:21:35PM +, Jan Beulich wrote:
> >>> On 05.12.14 at 16:50, wrote:
> > This bug (or lack of feature if you prefer) should be fixed, as it
> > was pointed out by Jan Beulich and Olaf Hering, by allocating conring
> > earlier. I though about that before posting this patc
On Fri, Dec 05, 2014 at 03:00:14PM +, Jan Beulich wrote:
> >>> 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? e
On Fri, 5 Dec 2014, Jan Beulich wrote:
> >>> On 05.12.14 at 17:05, wrote:
> > On 05/12/14 15:42, Jan Beulich wrote:
> > 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
The path to the pty of a Xen PV console is set only in
virDomainOpenConsole. But this is done too late. A call to
virDomainGetXMLDesc done before OpenConsole will not have the path to
the pty, but a call after OpenConsole will.
e.g. of the current issue.
Starting a domain with ''
Then:
virDomainGe
Hi,
I'm trying to fix an issue when using OpenStack with libvirt+xen (libxenlight).
OpenStack cannot access the console output of a Xen PV guest, because the XML
generated by libvirt for a domain is missing the path to the pty. The path
actually appear in the XML once one call virDomainOpenConsole
On Fri, Dec 05, 2014 at 10:42:27AM +, Andrew Cooper wrote:
> 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, base
On Fri, Dec 05, 2014 at 03:05:01PM +, Jan Beulich wrote:
> 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 -
Heh. Right.
> am I
>>> On 05.12.14 at 17:05, wrote:
> On 05/12/14 15:42, Jan Beulich wrote:
> 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. Shou
On Fri, Dec 05, 2014 at 04:11:48PM +, Ian Campbell wrote:
> On Fri, 2014-12-05 at 16:06 +, Wei Liu wrote:
> > Regarding JSON API, as Ian said, feel free to hook it up to libxlu.
>
> *If* it is useful to multiple toolstacks but not suitable for libxl then
> libxlu would be the right place.
>>> On 05.12.14 at 16:50, wrote:
> This bug (or lack of feature if you prefer) should be fixed, as it
> was pointed out by Jan Beulich and Olaf Hering, by allocating conring
> earlier. I though about that before posting this patch (I did not
> know beforehand about Olaf's work made in 2011). Howev
On Wed, Dec 03, 2014 at 08:39:47PM +0100, Luis R. Rodriguez wrote:
> On Wed, Dec 03, 2014 at 05:37:51AM +0100, Juergen Gross wrote:
> > On 12/03/2014 03:28 AM, Luis R. Rodriguez wrote:
> >> On Tue, Dec 02, 2014 at 11:11:18AM +, David Vrabel wrote:
> >>> On 01/12/14 22:36, Luis R. Rodriguez wrot
On Fri, Dec 05, 2014 at 09:28:44AM +0100, Olaf Hering wrote:
> 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 somethin
On Mon, Dec 01, 2014 at 05:24:35PM +0800, Tiejun Chen wrote:
> Before we refine RMRR mechanism, USB RMRR may conflict with guest bios
> region so we always ignore USB RMRR. Now this can be gone when we enable
> pci_force to check/reserve RMRR.
>
> Signed-off-by: Tiejun Chen
> ---
> xen/drivers/p
On Fri, 2014-12-05 at 16:06 +, Wei Liu wrote:
> Regarding JSON API, as Ian said, feel free to hook it up to libxlu.
*If* it is useful to multiple toolstacks but not suitable for libxl then
libxlu would be the right place.
As I understood things the need for JSON here was xl specific, and it i
On Fri, Dec 05, 2014 at 04:51:49PM +0100, Olaf Hering wrote:
> On Fri, Dec 05, Anthony PERARD wrote:
>
> > 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
I have to admit I'm confused by the back and forth discussion. It's hard
to justify the design of new API without knowing what the constraints
and requirements are from your PoV.
Here are my two cents, not about details, but about general constraints.
There are two layers, one is user of libxl (c
On 05/12/14 15:42, Jan Beulich wrote:
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
>> f
>>> On 05.12.14 at 16:55, wrote:
On 02.12.14 at 22:34, wrote:
>> +struct xen_sysctl_iotopo {
>> +uint16_t seg;
>> +uint8_t bus;
>> +uint8_t devfn;
>> +uint32_t node;
>> +};
>
> This is PCI-centric without expressing in the name or layout. Perhaps
> the first part should be a
>>> On 02.12.14 at 22:34, wrote:
> @@ -362,6 +363,35 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
> u_sysctl)
> u.topologyinfo.max_cpu_index) )
> ret = -EFAULT;
> }
> +
> +if ( !ret && !guest_handle_is_null(ti->i
>>> On 02.12.14 at 22:34, wrote:
> +struct xen_sysctl_iotopo {
> +uint16_t seg;
> +uint8_t bus;
> +uint8_t devfn;
> +uint32_t node;
> +};
This is PCI-centric without expressing in the name or layout. Perhaps
the first part should be a union from the very beginning?
Jan
>>> On 02.12.14 at 22:34, wrote:
> If ACPI provides PXM data for IO devices then dom0 will pass it to
> hypervisor during PHYSDEVOP_pci_device_add call. This information,
> however, is currently ignored.
>
> We should remember it (in the form of nodeID). We will also print it
> when user requests
On Fri, Dec 05, Anthony PERARD wrote:
> 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 optio
In general initial conring size is sufficient. However, if log
level is increased on platforms which have e.g. huge number
of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
which has more than 200 entries in EFI memory map) then some
of earlier messages in console ring are overwritten
On Fri, 2014-12-05 at 14:55 +, Ian Campbell wrote:
> Required by latest libvirt, to build docs.
>
> Signed-off-by: Ian Campbell
Ian acked this on IRC and I have pushed it along with some other bits
and bobs floating around already acked. Specifically I have pushed to
pretest:
0d8405e
>>> 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
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 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
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 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
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 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 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 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 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
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
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
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
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
>>> 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
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: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
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 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: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 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 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 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 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 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
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 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
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
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 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
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
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
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
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
@@
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
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:
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
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
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
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
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 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
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
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
1 - 100 of 154 matches
Mail list logo
