Re: [RFC v3 20/45] xen: dma-mapping: Use unsigned long for dma_attrs
On 02/06/16 16:39, Krzysztof Kozlowski wrote: > Split out subsystem specific changes for easier reviews. This will be > squashed with main commit. Acked-by: David Vrabel <david.vra...@citrix.com> David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 39/41] xen/events: use virt_xxx barriers
On 10/01/16 14:21, Michael S. Tsirkin wrote: > drivers/xen/events/events_fifo.c uses rmb() to communicate with the > other side. > > For guests compiled with CONFIG_SMP, smp_rmb would be sufficient, so > rmb() here is only needed if a non-SMP guest runs on an SMP host. > > Switch to the virt_rmb barrier which serves this exact purpose. > > Pull in asm/barrier.h here to make sure the file is self-contained. > > Suggested-by: David Vrabel <david.vra...@citrix.com> > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> Acked-by: David Vrabel <david.vra...@citrix.com> David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH v2 33/34] xenbus: use virt_xxx barriers
On 31/12/15 19:10, Michael S. Tsirkin wrote: > drivers/xen/xenbus/xenbus_comms.c uses > full memory barriers to communicate with the other side. > > For guests compiled with CONFIG_SMP, smp_wmb and smp_mb > would be sufficient, so mb() and wmb() here are only needed if > a non-SMP guest runs on an SMP host. > > Switch to virt_xxx barriers which serve this exact purpose. Acked-by: David Vrabel <david.vra...@citrix.com> If you're feeling particularly keen there's a rmb() consume_one_event() in drivers/xen/events/events_fifo.c that can be converted to virt_rmb() as well. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH v2 34/34] xen/io: use virt_xxx barriers
On 31/12/15 19:10, Michael S. Tsirkin wrote: > include/xen/interface/io/ring.h uses > full memory barriers to communicate with the other side. > > For guests compiled with CONFIG_SMP, smp_wmb and smp_mb > would be sufficient, so mb() and wmb() here are only needed if > a non-SMP guest runs on an SMP host. > > Switch to virt_xxx barriers which serve this exact purpose. Acked-by: David Vrabel <david.vra...@citrix.com> David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH v3 11/20] tty/hvc: xen: Use xen page definition
On 07/08/15 17:46, Julien Grall wrote: The console ring is always based on the page granularity of Xen. [...] --- a/drivers/tty/hvc/hvc_xen.c +++ b/drivers/tty/hvc/hvc_xen.c @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void) if (r 0 || v == 0) goto err; gfn = v; - info-intf = xen_remap(gfn PAGE_SHIFT, PAGE_SIZE); + info-intf = xen_remap(gfn XEN_PAGE_SHIFT, PAGE_SIZE); You need XEN_PAGE_SIZE here I think... if (info-intf == NULL) goto err; info-vtermno = HVC_COOKIE; @@ -472,7 +472,7 @@ static int xencons_resume(struct xenbus_device *dev) struct xencons_info *info = dev_get_drvdata(dev-dev); xencons_disconnect_backend(info); - memset(info-intf, 0, PAGE_SIZE); + memset(info-intf, 0, XEN_PAGE_SIZE); ...particularly since you use it here. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH v3 0/9] Use correctly the Xen memory terminologies
On 07/08/15 17:34, Julien Grall wrote: Hi all, This patch series aims to use the memory terminologies described in include/xen/mm.h [1] for Linux xen code. Applied to for-linus-4.3, thanks. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
On 29/07/15 12:35, Julien Grall wrote:
Hi Wei,
On 29/07/15 11:13, Wei Liu wrote:
On Tue, Jul 28, 2015 at 04:02:45PM +0100, Julien Grall wrote:
[...]
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 7d50711..3b7b7c3 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue
*queue, struct sk_buff *skb
} else {
copy_gop-source.domid = DOMID_SELF;
copy_gop-source.u.gmfn =
- virt_to_mfn(page_address(page));
+ virt_to_gfn(page_address(page));
}
copy_gop-source.offset = offset;
@@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue
*queue,
queue-tx_copy_ops[*copy_ops].source.offset = txreq.offset;
queue-tx_copy_ops[*copy_ops].dest.u.gmfn =
- virt_to_mfn(skb-data);
+ virt_to_gfn(skb-data);
queue-tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
queue-tx_copy_ops[*copy_ops].dest.offset =
offset_in_page(skb-data);
Reviewed-by: Wei Liu wei.l...@citrix.com
One possible improvement is to change gmfn in copy_gop to gfn as well.
But that's outside of netback code.
The structure gnttab_copy is part of the hypervisor interface. Is it
fine to differ on the naming between Xen and Linux?
Or maybe we could do the change in the public headers in Xen repo too.
Is it fine to do field renaming in public headers?
I think this series should not alter than Xen API.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
On 28/07/15 16:02, Julien Grall wrote: Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN is meant, I suspect this is because the first support for Xen was for PV. This brough some misimplementation of helpers on ARM and make the developper confused the expected behavior. For the benefit of other subsystem maintainers, this is a purely mechanical change in Xen-specific terminology. It doesn't need reviews or acks from non-Xen people (IMO). For instance, with pfn_to_mfn, we expect to get an MFN based on the name. Although, if we look at the implementation on x86, it's returning a GFN. For clarity and avoid new confusion, replace any reference of mfn into gnf in any helpers used by PV drivers. Take also the opportunity to simplify simple construction such as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up will come in follow-up patches. I think it may be possible to do further clean up in the x86 code to ensure that helpers returning machine address (such as virt_address) is not used by no auto-translated guests. I will let x86 xen expert doing it. Reviewed-by: David Vrabel david.vra...@citrix.com It looks a bit odd to use GFN in some of the PV code where the hypervisor API uses MFN but overall I think using the correct terminology where possible is best. But I'd like to have Boris's or Konrad's opinion on this. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH 7/8] hvc/xen: Further s/MFN/GFN clean-up
On 28/07/15 16:02, Julien Grall wrote: HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM guest. It returns a PFN (aka GFN) and not a MFN. Furthermore, use directly virt_to_gfn for both PV and HVM domain rather than doing a special case for each of the them. Reviewed-by: David Vrabel david.vra...@citrix.com David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 11/20] tty/hvc: xen: Use xen page definition
On 09/07/15 21:42, Julien Grall wrote: The console ring is always based on the page granularity of Xen. [...] --- a/drivers/tty/hvc/hvc_xen.c +++ b/drivers/tty/hvc/hvc_xen.c @@ -392,7 +392,7 @@ static int xencons_connect_backend(struct xenbus_device *dev, if (xen_pv_domain()) mfn = virt_to_mfn(info-intf); else - mfn = __pa(info-intf) PAGE_SHIFT; + mfn = __pa(info-intf) XEN_PAGE_SHIFT; Change this to gfn = xen_page_to_gfn(virt_to_page(info-intf)); and drop the if()? David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH v2 1/3] drivers/xen/preempt: use need_resched() instead of should_resched()
On 15/07/15 10:52, Konstantin Khlebnikov wrote: This code is used only when CONFIG_PREEMPT=n and only in non-atomic context: xen_in_preemptible_hcall is set only in privcmd_ioctl_hypercall(). Thus preempt_count is zero and should_resched() is equal to need_resched(). Applied to for-linus-4.3, thanks. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] hvc_xen: avoid uninitialized variable warning
On 28/05/15 09:28, Jan Beulich wrote: Older compilers don't recognize that v can't be used uninitialized; other code using hvm_get_parameter() zeros the value too, so follow suit here. Applied to for-linus-4.2, thanks. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH 3/8] x86/xen/p2m: Replace ACCESS_ONCE with READ_ONCE
On 15/01/15 08:58, Christian Borntraeger wrote: ACCESS_ONCE does not work reliably on non-scalar types. For example gcc 4.6 and 4.7 might remove the volatile tag for such accesses during the SRA (scalar replacement of aggregates) step (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145) Change the p2m code to replace ACCESS_ONCE with READ_ONCE. Acked-by: David Vrabel david.vra...@citrix.com Let me know if you want me to merge this via the Xen tree. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH v1 04/21] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
On 11/09/14 02:22, Yijing Wang wrote: On 2014/9/10 20:36, David Vrabel wrote: On 05/09/14 11:09, Yijing Wang wrote: Commit 0e4ccb150 added two __weak arch functions arch_msix_mask_irq() and arch_msi_mask_irq() to fix a bug found when running xen in x86. Introduced these two funcntions make MSI code complex. And mask/unmask is the irq actions related to interrupt controller, should not use weak arch functions to override mask/unmask interfaces. This patch reverted commit 0e4ccb150 and export struct irq_chip msi_chip, modify msi_chip-irq_mask/irq_unmask() in xen init functions to fix this bug for simplicity. Also this is preparation for using struct msi_chip instead of weak arch MSI functions in all platforms. Acked-by: David Vrabel david.vra...@citrix.com But I wonder if it would be better the Xen subsystem to provide its own struct irq_chip instead of adjusting the fields in the generic x86 one. Thanks! Currently, Xen and the bare x86 system only have the different irq_chip-irq_mask/irq_unmask. So I chose to override the two ops of bare x86 irq_chip in xen. Konrad Rzeszutek Wilk has been tested it ok in his platform, so I think we could use its own irq_chip for xen later if the difference become large. This sounds reasonable. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH v1 04/21] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
On 05/09/14 11:09, Yijing Wang wrote: Commit 0e4ccb150 added two __weak arch functions arch_msix_mask_irq() and arch_msi_mask_irq() to fix a bug found when running xen in x86. Introduced these two funcntions make MSI code complex. And mask/unmask is the irq actions related to interrupt controller, should not use weak arch functions to override mask/unmask interfaces. This patch reverted commit 0e4ccb150 and export struct irq_chip msi_chip, modify msi_chip-irq_mask/irq_unmask() in xen init functions to fix this bug for simplicity. Also this is preparation for using struct msi_chip instead of weak arch MSI functions in all platforms. Acked-by: David Vrabel david.vra...@citrix.com But I wonder if it would be better the Xen subsystem to provide its own struct irq_chip instead of adjusting the fields in the generic x86 one. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH v1 08/21] x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On 09/09/14 03:06, Yijing Wang wrote: On 2014/9/5 22:29, David Vrabel wrote: On 05/09/14 11:09, Yijing Wang wrote: Use MSI chip framework instead of arch MSI functions to configure MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework. [...] --- a/arch/x86/pci/xen.c +++ b/arch/x86/pci/xen.c [...] @@ -418,9 +430,9 @@ int __init pci_xen_init(void) #endif #ifdef CONFIG_PCI_MSI - x86_msi.setup_msi_irqs = xen_setup_msi_irqs; - x86_msi.teardown_msi_irq = xen_teardown_msi_irq; - x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs; + xen_msi_chip.setup_irqs = xen_setup_msi_irqs; + xen_msi_chip.teardown_irqs = xen_teardown_msi_irqs; + x86_msi_chip = xen_msi_chip; msi_chip.irq_mask = xen_nop_msi_mask; msi_chip.irq_unmask = xen_nop_msi_mask; Why have these not been changed to set the x86_msi_chip.mask/unmask fields instead? Hi David, x86_msi_chip here is struct msi_chip data type, used to configure MSI/MSI-X irq. msi_chip above is struct irq_chip data type, represent the MSI irq controller. They are not the same object. Their name easily confusing people. Ok, it all makes sense now. Acked-by: David Vrabel david.vra...@citrix.com David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [PATCH v1 08/21] x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On 05/09/14 11:09, Yijing Wang wrote: Use MSI chip framework instead of arch MSI functions to configure MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework. [...] --- a/arch/x86/pci/xen.c +++ b/arch/x86/pci/xen.c [...] @@ -418,9 +430,9 @@ int __init pci_xen_init(void) #endif #ifdef CONFIG_PCI_MSI - x86_msi.setup_msi_irqs = xen_setup_msi_irqs; - x86_msi.teardown_msi_irq = xen_teardown_msi_irq; - x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs; + xen_msi_chip.setup_irqs = xen_setup_msi_irqs; + xen_msi_chip.teardown_irqs = xen_teardown_msi_irqs; + x86_msi_chip = xen_msi_chip; msi_chip.irq_mask = xen_nop_msi_mask; msi_chip.irq_unmask = xen_nop_msi_mask; Why have these not been changed to set the x86_msi_chip.mask/unmask fields instead? David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Xen-devel] [RFC PATCH 01/20] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
On 12/08/14 08:25, Yijing Wang wrote:
Commit 0e4ccb150 added two __weak arch functions arch_msix_mask_irq()
and arch_msi_mask_irq() to fix a bug found when running xen in x86.
Introduced these two funcntions make MSI code complex. This patch
reverted commit 0e4ccb150 and add #ifdef for x86 msi_chip to fix this
bug for simplicity. Also this is preparation for using struct
msi_chip instead of weak arch MSI functions in all platforms.
[...]
static struct irq_chip msi_chip = {
.name = PCI-MSI,
+#ifdef CONFIG_XEN
+ .irq_unmask = nop_unmask_msi_irq,
+ .irq_mask = nop_mask_msi_irq,
+#else
.irq_unmask = unmask_msi_irq,
.irq_mask = mask_msi_irq,
+#endif
No. CONFIG_XEN kernels can run on Xen and bare metal so this must be a
runtime option.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] drivers/tty/hvc: don't use module_init in non-modular hyp. console code
On 15/01/14 21:35, Paul Gortmaker wrote: The HVC_OPAL/RTAS/UDBG/XEN options are all bool, and hence their support is either present or absent. It will never be modular, so using module_init as an alias for __initcall is rather misleading. Fix this up now, so that we can relocate module_init from init.h into module.h in the future. If we don't do this, we'd have to add module.h to obviously non-modular code, and that would be a worse thing. Note that direct use of __initcall is discouraged, vs. one of the priority categorized subgroups. As __initcall gets mapped onto device_initcall, our use of device_initcall directly in this change means that the runtime impact is zero -- it will remain at level 6 in initcall ordering. Also the __exitcall functions have been outright deleted since they are only ever of interest to UML, and UML will never be using any of this code. For the hvc_xen changes Acked-by: David Vrabel david.vra...@citrix.com Thanks David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] sdhci-of: Fix high-speed cards recognition
Anton Vorontsov wrote: eSDHC fails to recognize some SDHS cards, throwing timeout errors: mmc0: error -110 whilst initialising SD card That's because we calculate timeout value in a wrong way: on eSDHC hosts the timeout clock is derivied from the SD clock, which is set dynamically. I've seen an reference design for an SDHC controller do this also. +/* Controller has dynamic timeout clock management */ +#define SDHCI_QUIRK_DYNAMIC_TIMEOUT_CLOCK(124) This comment and define would be better if it matched terms used in the spec. Suggest: /* Controller uses SDCLK instead of TMCLK for data timeouts. */ #define SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK (1 24) David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ 'member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom' ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
