> From: Tian, Kevin
> Sent: Wednesday, November 19, 2014 4:18 PM
>
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Wednesday, November 12, 2014 5:57 PM
> >
> > >>> 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:
> > >>>
>>> On 19.11.14 at 02:26, wrote:
>> > So without lookuping devices[i], how can we call func() for each sbdf as
>>> you mentioned?
>>
>> You've got both rmrr and bdf in the body of for_each_rmrr_device().
>> After all - as I said - you just open-coded it.
>>
>
> Yeah, so change this again,
>
> in
On 11/19/2014 09:41 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Nov 11, 2014 at 06:43:38AM +0100, Juergen Gross wrote:
Paravirtualized kernels running on Xen use a three level tree for
translation of guest specific physical addresses to machine global
addresses. This p2m tree is used for constructi
On 11/19/2014 08:43 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Nov 14, 2014 at 06:14:06PM +0100, Juergen Gross wrote:
On 11/14/2014 05:47 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Nov 14, 2014 at 05:53:19AM +0100, Juergen Gross wrote:
On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
+
On 11/19/2014 10:04 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Nov 14, 2014 at 10:37:25AM +0100, Juergen Gross wrote:
Introduce a new boot parameter "virt_p2m" to be able to set
XENFEAT_virtual_p2m for a pv domain.
As long as Xen tools and kdump don't support this new feature it is
turned off by
On 11/17/2014 23:54, Jan Beulich wrote:
On 17.11.14 at 20:21, wrote:
Okay, I did a bisection and was not able to correlate the above error
message with the problem I'm seeing. Not saying it's not related, but I
had plenty of successful test runs in the presence of that error.
Took me about a w
flight 31675 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31675/
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
Tests which are failin
On Tue, Nov 18, 2014 at 04:49:21PM +, Stefano Stabellini wrote:
> ping?
Sending something which wants my attention _To:_ me is always a good idea :)
The patch is fine in itself, but I have a niggle about the
is_device_dma_coherent() - provided this is only used in architecture
specific code,
If we pass in INTx type devices to a guest on an over-subscribed
machine - and in an over-worked guest - we can cause the
pirq_dpci->softirq_list to become corrupted.
The reason for this is that the 'pt_irq_guest_eoi' ends up
setting the 'state' to zero value. However the 'state' value
(STATE_SCHE
When we want to cancel an outstanding 'struct hvm_pirq_dpci' we perform
and cmpxch on the state to set it to zero. That is OK on the teardown
paths as it is guarnateed that the do_IRQ action handler has been removed.
Hence no more interrupts can be scheduled. But with the introduction
of "dpci: Fix
Hey,
Attached are two patches that fix the dpci_softirq list corruption
that Sander was observing.
xen/drivers/passthrough/io.c | 55 +++-
1 file changed, 39 insertions(+), 16 deletions(-)
Konrad Rzeszutek Wilk (2):
dpci: Fix list corruption if INT
On Wed, Nov 19, 2014 at 08:17:35PM +0100, Sander Eikelenboom wrote:
>
> Wednesday, November 19, 2014, 8:01:31 PM, you wrote:
>
> > On Wed, Nov 19, 2014 at 07:54:39PM +0100, Sander Eikelenboom wrote:
> >>
> >> Wednesday, November 19, 2014, 6:31:39 PM, you wrote:
> >>
> >> > Hey,
> >>
> >> > Thi
On Sun, Nov 16, 2014 at 10:36:28AM +0800, Simon Cao wrote:
> Hi,
>
> I was working on the work. But I was busing preparing some job interviews
> in the last three months, sorry for this long delay. I will update my
> progress in a few days.
OK, I put your name for this to be in Xen 4.6.
Thanks!
On Wed, Nov 19, 2014 at 09:21:23PM +, Wei Liu wrote:
> On Wed, Nov 19, 2014 at 04:01:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 17, 2014 at 12:10:34PM +, Wei Liu wrote:
> > > The existence check is to make sure a device is not added to a guest
> > > multiple times.
> > >
> >
On Wed, Nov 19, 2014 at 03:27:48PM +, Ian Campbell wrote:
> These patches:
>
> * fix up an off by one bug in the xgene mapping of additional PCI
> bus resources, which would cause an additional extra page to be
> mapped
> * correct the size of the mapped regions to
On Wed, Nov 19, 2014 at 11:26:32AM +, Ian Jackson wrote:
> Hi Konrad, I have another release ack request:
>
> Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> > Currently libxl__domain_rename only update /local/domain//name,
> > still some places in xenstore are
On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > Before this patch, pv guest video_memkb is -1, which is an invalid value.
> > And it will cause the xenstore 'memory/targe' calculation wrong:
> >
> > memo
On Wed, Nov 19, 2014 at 11:22:18AM +, Ian Campbell wrote:
> On Wed, 2014-11-19 at 11:17 +, Andrew Cooper wrote:
> > In both of these cases, markdown was interpreting the text as regular text,
> > and reflowing it as a regular paragraph, leading to a single line as output.
> > Reformat them
On Wed, Nov 19, 2014 at 04:01:54PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 17, 2014 at 12:10:34PM +, Wei Liu wrote:
> > The existence check is to make sure a device is not added to a guest
> > multiple times.
> >
> > PCI device backend path has different rules from vif, disk etc. For
On Tue, Nov 18, 2014 at 04:51:42PM +, Ian Campbell wrote:
> On Tue, 2014-11-18 at 16:44 +, Ian Campbell wrote:
> > These patches:
>
> ... which are also at
> git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v1
I presume you are going to post v2 with Julian's feedback rolled in?
On Tue, Nov 18, 2014 at 04:44:46PM +, Ian Campbell wrote:
> The callers pass the end as the pfn immediately *after* the last page to be
> mapped, therefore adding one is incorrect and causes an additional page to be
> mapped.
>
> At the same time correct the printing of the mfn values, zero-pa
On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> Before this patch, pv guest video_memkb is -1, which is an invalid value.
> And it will cause the xenstore 'memory/targe' calculation wrong:
>
> memory/target = info->target_memkb - info->video_memkb
CC-ing the maintainers.
Is t
On Wed, Nov 12, 2014 at 11:40:53AM +, Stefano Stabellini wrote:
> xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
> handle as argument, not a physical address.
Ouch. Should this also go on stable tree?
>
> Signed-off-by: Stefano Stabellini
> Reviewed-by: Catalin Marinas
On Wed, Nov 12, 2014 at 11:40:54AM +, Stefano Stabellini wrote:
> 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 ph
On Fri, Nov 14, 2014 at 10:37:25AM +0100, Juergen Gross wrote:
> Introduce a new boot parameter "virt_p2m" to be able to set
> XENFEAT_virtual_p2m for a pv domain.
>
> As long as Xen tools and kdump don't support this new feature it is
> turned off by default.
Couldn't the dom0_large and dom0 be
On Mon, Nov 17, 2014 at 12:10:34PM +, Wei Liu wrote:
> The existence check is to make sure a device is not added to a guest
> multiple times.
>
> PCI device backend path has different rules from vif, disk etc. For
> example:
> /local/domain/0/backend/pci/9/0/dev-1/:03:10.1
> /local/domain/
On Fri, Nov 14, 2014 at 10:29:26AM +, Ian Campbell wrote:
> On Thu, 2014-11-13 at 16:29 +, Thomas Leonard wrote:
> > On 27 October 2014 10:34, Ian Campbell wrote:
> > > On Sun, 2014-10-26 at 09:51 +, Thomas Leonard wrote:
> > >> On 21 October 2014 11:50, Ian Campbell wrote:
> > >> > O
On Wed, Nov 19, 2014 at 12:12:09PM -0300, Simon Martin wrote:
> Hello Jan and Konrad,
>
> Tuesday, November 18, 2014, 1:49:13 PM, you wrote:
>
> >>
> >> I've just checked this with lspci. I see that the IO is being enabled.
>
> > Memory you mean.
>
> Yes. Sorry.
>
> >> Any other idea on
On Tue, Nov 11, 2014 at 06:43:38AM +0100, Juergen Gross wrote:
> Paravirtualized kernels running on Xen use a three level tree for
> translation of guest specific physical addresses to machine global
> addresses. This p2m tree is used for construction of page table
> entries, so the p2m tree walk i
On Tue, Nov 11, 2014 at 06:43:46AM +0100, Juergen Gross wrote:
> Instead of checking at each call of set_phys_to_machine() whether a
> new p2m page has to be allocated due to writing an entry in a large
> invalid or identity area, just map those areas read only and react
> to a page fault on write
On Thu, Nov 13, 2014 at 10:21:01AM +0100, Juergen Gross wrote:
> On 11/11/2014 06:47 PM, David Vrabel wrote:
> >On 11/11/14 05:43, Juergen Gross wrote:
> >>At start of the day the Xen hypervisor presents a contiguous mfn list
> >>to a pv-domain. In order to support sparse memory this mfn list is
>
On Tue, Nov 11, 2014 at 06:43:45AM +0100, Juergen Gross wrote:
> At start of the day the Xen hypervisor presents a contiguous mfn list
> to a pv-domain. In order to support sparse memory this mfn list is
> accessed via a three level p2m tree built early in the boot process.
> Whenever the system ne
Currently the quirk code for SandyBridge uses the VTd timeout value when
writing to an IGD register. This is the wrong timeout to use and, at
1000 msec., is also much too large. This patch changes the quirk code to
use a timeout that is specific to the IGD device and allows the user
control of th
On Fri, Nov 14, 2014 at 10:10:58AM +, Ian Campbell wrote:
> (CCing some more maintainers and the release manager)
>
> On Wed, 2014-11-12 at 15:43 +, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:38 -0600, Clark Laughlin wrote:
> > > mkdeb previously set the package architecture to be 'a
On Fri, Nov 14, 2014 at 06:14:06PM +0100, Juergen Gross wrote:
> On 11/14/2014 05:47 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Nov 14, 2014 at 05:53:19AM +0100, Juergen Gross wrote:
> >>On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
> >>+ mfn_save = virt_to_mfn(buf);
> >>+
> >
On 11/19/14 13:18, Stefano Stabellini wrote:
On Wed, 19 Nov 2014, Don Slutz wrote:
I have posted the patch:
Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off
for xenfv machine
Date: Wed, 19 Nov 2014 12:30:57 -0500
Message-ID: <1416418257-10166-1-git-send-email-dsl...@
flight 31670 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31670/
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. 31536
Tests which did n
19 лист. 2014 20:32, користувач "Stefano Stabellini" <
stefano.stabell...@eu.citrix.com> написав:
>
> On Wed, 19 Nov 2014, Julien Grall wrote:
> > On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > > That's right, the maintenance interrupt handler is not called, but it
> > > doesn't do anything
On 19/11/2014 18:54, Sander Eikelenboom wrote:
> Wednesday, November 19, 2014, 6:31:39 PM, you wrote:
>
>> Hey,
>> This patch should fix the issue that Sander had seen. The full details
>> are in the patch itself. Sander, if you could - please test origin/staging
>> with this patch to make sure it
Wednesday, November 19, 2014, 6:31:39 PM, you wrote:
> Hey,
> This patch should fix the issue that Sander had seen. The full details
> are in the patch itself. Sander, if you could - please test origin/staging
> with this patch to make sure it does fix the issue.
> xen/drivers/passthrough/io.
On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 05:44:49PM +, Stefano Stabellini wrote:
> > UIE being set can cause maintenance interrupts to occur when Xen writes
> > to one or more LR registers. The effect is a busy loop around the
> > interrupt handler in Xen
> >
On Wed, 19 Nov 2014, Julien Grall wrote:
> On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > That's right, the maintenance interrupt handler is not called, but it
> > doesn't do anything so we are fine. The important thing is that an
> > interrupt is sent and git_clear_lrs gets called on hyperv
On Wed, Nov 19, 2014 at 05:44:49PM +, Stefano Stabellini wrote:
> UIE being set can cause maintenance interrupts to occur when Xen writes
> to one or more LR registers. The effect is a busy loop around the
> interrupt handler in Xen
> (http://marc.info/?l=xen-devel&m=141597517132682): everythin
On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> That's right, the maintenance interrupt handler is not called, but it
> doesn't do anything so we are fine. The important thing is that an
> interrupt is sent and git_clear_lrs gets called on hypervisor entry.
It would be worth to write down this
On Wed, 19 Nov 2014, Don Slutz wrote:
> I have posted the patch:
>
> Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off
> for xenfv machine
> Date: Wed, 19 Nov 2014 12:30:57 -0500
> Message-ID: <1416418257-10166-1-git-send-email-dsl...@verizon.com>
>
>
> Which fixes QEM
That's right, the maintenance interrupt handler is not called, but it
doesn't do anything so we are fine. The important thing is that an
interrupt is sent and git_clear_lrs gets called on hypervisor entry.
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> The only ambiguity left - maintenance inter
The only ambiguity left - maintenance interrupt handler is not called.
It was requested for specific IRQ number, retrieved from device tree.
But when we trigger GICH_HCR_UIE - we got maintenance interrupt for
spurious number 1023.
Regards,
Andrii
On Wed, Nov 19, 2014 at 7:47 PM, Andrii Tseglytsky
On Wed, 19 Nov 2014, David Vrabel wrote:
> 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
> dm
UIE being set can cause maintenance interrupts to occur when Xen writes
to one or more LR registers. The effect is a busy loop around the
interrupt handler in Xen
(http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
Konrad, this fixes an actual bug, at least on OMAP5. It shoul
I have posted the patch:
Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off
for xenfv machine
Date: Wed, 19 Nov 2014 12:30:57 -0500
Message-ID: <1416418257-10166-1-git-send-email-dsl...@verizon.com>
Which fixes QEMU 2.2 for xenfv. However if you configure xen_platfor
On Wed, Nov 19, 2014 at 7:42 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
>> wrote:
>> > I think that's OK: it looks like that on your board for some reasons
>> > when UIE is set you get irq
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
> wrote:
> > I think that's OK: it looks like that on your board for some reasons
> > when UIE is set you get irq 1023 (spurious interrupt) instead of your
> > normal maintenance i
No, it just means "spurious interrupt".
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Does number 1023 mean that maintenance interrupt is global?
>
> On Wed, Nov 19, 2014 at 7:03 PM, Andrii Tseglytskyi
> wrote:
> > I got this strange log:
> >
> > (XEN) received maintenance interrupt irq=1023
Hi Stefano,
On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
wrote:
> I think that's OK: it looks like that on your board for some reasons
> when UIE is set you get irq 1023 (spurious interrupt) instead of your
> normal maintenance interrupt.
OK, but I think this should be investigated too. W
On Wed, 19 Nov 2014, David Vrabel wrote:
> Signed-off-by: David Vrabel
> Cc: Tony Luck
> Cc: Fenghua Yu
> Cc: linux-i...@vger.kernel.org
Reviewed-by: Stefano Stabellini
> arch/ia64/include/asm/machvec.h |2 +-
> arch/ia64/include/asm/machvec_init.h |1 -
> arch/ia64/pci/pci.c
Hey,
This patch should fix the issue that Sander had seen. The full details
are in the patch itself. Sander, if you could - please test origin/staging
with this patch to make sure it does fix the issue.
xen/drivers/passthrough/io.c | 27 +--
Konrad Rzeszutek Wilk (1):
If we pass in INTx type devices to a guest on an over-subscribed
machine - and in an over-worked guest - we can cause the
pirq_dpci->softirq_list to become corrupted.
The reason for this is that the 'pt_irq_guest_eoi' ends up
setting the 'state' to zero value. However the 'state' value
(STATE_SCHE
Wednesday, November 19, 2014, 4:04:59 PM, you wrote:
> On Wed, Nov 19, 2014 at 12:16:44PM +0100, Sander Eikelenboom wrote:
>>
>> Wednesday, November 19, 2014, 2:55:41 AM, you wrote:
>>
>> > On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
>> >>
>> >> Tuesday, November 18, 20
I think that's OK: it looks like that on your board for some reasons
when UIE is set you get irq 1023 (spurious interrupt) instead of your
normal maintenance interrupt.
But everything should work anyway without issues.
This is the same patch as before but on top of the lastest xen-unstable
tree.
Does number 1023 mean that maintenance interrupt is global?
On Wed, Nov 19, 2014 at 7:03 PM, Andrii Tseglytskyi
wrote:
> I got this strange log:
>
> (XEN) received maintenance interrupt irq=1023
>
> And platform does not hang due to this:
> +hcr = GICH[GICH_HCR];
> +if ( hcr & GICH_HCR_UI
I got this strange log:
(XEN) received maintenance interrupt irq=1023
And platform does not hang due to this:
+hcr = GICH[GICH_HCR];
+if ( hcr & GICH_HCR_UIE )
+{
+GICH[GICH_HCR] &= ~GICH_HCR_UIE;
+uie_on = 1;
+}
On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
No, that's for requesting a maintenance interrupt for a specific irq
when it is EOI'ed by the guest.
In our case we are requesting maintenance interrupts via UIE: a single
global maintenance interrupt when most LRs become free.
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> BTW - shouldn't this
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >> wrote:
> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >> >
On Fri, Nov 14, 2014 at 11:11:46AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 03:13:42PM +, Jan Beulich wrote:
> > >>> On 12.11.14 at 03:23, wrote:
> > > +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
> > > +{
> > > +struct domain *d = pirq_dpci->dom
BTW - shouldn't this flag GICH_LR_MAINTENANCE_IRQ be set after
maintenance interrupt requesting ?
On Wed, Nov 19, 2014 at 6:32 PM, Andrii Tseglytskyi
wrote:
> Gic dump during interrupt requesting:
>
> (XEN) GICH_LRs (vcpu 0) mask=f
> (XEN)HW_LR[0]=3a1f
> (XEN)HW_LR[1]=9a015856
> (XEN)
Gic dump during interrupt requesting:
(XEN) GICH_LRs (vcpu 0) mask=f
(XEN)HW_LR[0]=3a1f
(XEN)HW_LR[1]=9a015856
(XEN)HW_LR[2]=1a1b
(XEN)HW_LR[3]=9a00e439
(XEN) Inflight irq=31 lr=0
(XEN) Inflight irq=86 lr=1
(XEN) Inflight irq=27 lr=2
(XEN) Inflight irq=57 lr=3
(XEN) Infligh
On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>> wrote:
>> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>> > wrote:
>> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> wrote:
> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> > wrote:
> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> Hi Stefano,
> >>>
> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefa
On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
wrote:
> On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> wrote:
>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> Hi Stefano,
>>>
>>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>> wrote:
>>> > On Wed, 19 Nov 2014, Andrii Tse
Signed-off-by: David Vrabel
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 changed, 1 insertion(+), 22 deleti
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
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 Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi Stefano,
>> >>
>> >> > > if ( !list_empt
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 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
On Wed, 19 Nov 2014, Fabio Fantoni wrote:
> Il 19/11/2014 15:56, Don Slutz ha scritto:
> > I think I know what is happening here. But you are pointing at the wrong
> > change.
> >
> > commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
> >
> > Is what I am guessing at this time is the issue. I thin
Il 19/11/2014 15:56, Don Slutz ha scritto:
I think I know what is happening here. But you are pointing at the
wrong change.
commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
Is what I am guessing at this time is the issue. I think that
xen_enabled() is
returning false in pc_machine_initfn. W
flight 31669 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31669/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a
test-amd64-amd64-rumpuserxen-amd64
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi Stefano,
> >>
> >> > > if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full()
> >> > > )
> >> > > -
The region assigned to PCIE0, according to the docs, is 0x0e0 to
0x100. They make no distinction between PCI CFG and PCI IO mem within
this range (in fact, I'm not sure that isn't up to the driver).
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
xen/arch/arm/platforms
EARLY_PRINTK_BAUD doesn't do anything unless EARLY_PRINTK_INIT_UART is set.
Furthermore only the pl011 driver implements the init routine at all, so the
entries which use 8250 and specified a BAUD were doubly wrong.
Signed-off-by: Ian Campbell
---
v2: New patch.
---
xen/arch/arm/Rules.mk |7
The callers pass the end as the pfn immediately *after* the last page to be
mapped, therefore adding one is incorrect and causes an additional page to be
mapped.
At the same time correct the printing of the mfn values, zero-padding them to
16 digits as for a paddr when they are frame numbers is ju
Signed-off-by: Ian Campbell
---
v2: Remove pointless/unused baud rate setting.
A bunch of other entries have these, but cleaning them up is out of scope here
I think.
---
xen/arch/arm/Rules.mk |5 +
1 file changed, 5 insertions(+)
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules
Currently we only establish specific mappings for pcie0, which is
used on the Mustang platform. However at least McDivitt uses pcie3.
So wire up all the others, based on whether the corresponding DT node
is marked as available.
This results in no change for Mustang.
Signed-off-by: Ian Campbell
-
These patches:
* fix up an off by one bug in the xgene mapping of additional PCI
bus resources, which would cause an additional extra page to be
mapped
* correct the size of the mapped regions to match the docs
* adds support for the other 4 PCI buses on the chip,
Hi Stefano,
On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> > > if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full() )
>> > > -GICH[GICH_HCR] |= GICH_HCR_UIE;
>> > > +GICH[GICH_HCR] |= G
Hello Jan and Konrad,
Tuesday, November 18, 2014, 1:49:13 PM, you wrote:
>>
>> I've just checked this with lspci. I see that the IO is being enabled.
> Memory you mean.
Yes. Sorry.
>> Any other idea on why I might be reading back 0xff for all PCI
>> memory area reads? The lspci output
On Wed, Nov 19, 2014 at 12:16:44PM +0100, Sander Eikelenboom wrote:
>
> Wednesday, November 19, 2014, 2:55:41 AM, you wrote:
>
> > On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
> >>
> >> Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
> >>
> >> >>
> >> >> Uhmm i though
I think I know what is happening here. But you are pointing at the
wrong change.
commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
Is what I am guessing at this time is the issue. I think that
xen_enabled() is
returning false in pc_machine_initfn. Where as in pc_init1 is is
returning true.
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> > > if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full() )
> > > -GICH[GICH_HCR] |= GICH_HCR_UIE;
> > > +GICH[GICH_HCR] |= GICH_HCR_NPIE;
> > > else
> > > -GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >
On 11/19/2014 01:30 PM, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 3:26 PM, Julien Grall wrote:
>> On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
>>> Hi Julien,
>>>
>>> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall
>>> wrote:
On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>>>
Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid
leaf with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches,
and qemu 2.2 from spice git (spice/next commit
e779fa0a715530311e6f59fc8adb0f6eca914a89):
https://github.com/
On Wed, Nov 19, 2014 at 3:26 PM, Julien Grall wrote:
> On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
>> Hi Julien,
>>
>> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall
>> wrote:
>>> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
On Wed, 19 Nov 2014, Ian Campbell wrote:
> On Wed, 2
On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
> Hi Julien,
>
> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall wrote:
>> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>>> On Wed, 19 Nov 2014, Ian Campbell wrote:
On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
> So it l
Hi Julien,
On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall wrote:
> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>> On Wed, 19 Nov 2014, Ian Campbell wrote:
>>> On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
So it looks like there is not actually anything wrong, is just that
Hi Stefano,
> > if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full() )
> > -GICH[GICH_HCR] |= GICH_HCR_UIE;
> > +GICH[GICH_HCR] |= GICH_HCR_NPIE;
> > else
> > -GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > +GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >
> > }
>
> Ye
On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Ian Campbell wrote:
>> On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
>>> So it looks like there is not actually anything wrong, is just that you
>>> have too much inflight irqs? It should cause problems because
On Wed, 19 Nov 2014, Ian Campbell wrote:
> On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
> > So it looks like there is not actually anything wrong, is just that you
> > have too much inflight irqs? It should cause problems because in that
> > case GICH_HCR_UIE should be set and you s
On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
> So it looks like there is not actually anything wrong, is just that you
> have too much inflight irqs? It should cause problems because in that
> case GICH_HCR_UIE should be set and you should get a maintenance
> interrupt when LRs beco
On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On November 19, 2014 5:52:58 AM EST, Stefano Stabellini
> wrote:
> >ping?
> >
> >On Tue, 18 Nov 2014, Stefano Stabellini wrote:
> >> Konrad,
> >> I think we should have this fix in Xen 4.5. Should I go ahead and
> >> backport it?
>
> Go for it.
1 - 100 of 139 matches
Mail list logo
