* Re: Xen-devel Digest, Vol 116, Issue 297
[not found] <mailman.1894.1413205759.1420.xen-devel@lists.xen.org>
@ 2014-10-13 13:36 ` jefby
2014-10-13 15:13 ` Julien Grall
0 siblings, 1 reply; 2+ messages in thread
From: jefby @ 2014-10-13 13:36 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 18484 bytes --]
Hello , every one.I am jefby,recently i want to port Xen4.4 to arndale
octa,and i found some information about this in mail lists,and now i want
to know are there some useful or available u-boot source git repo for
arndale octa board to enter into hvp mode ??
Thanks very much!
jefby
2014-10-13 21:09 GMT+08:00 <xen-devel-request@lists.xen.org>:
> Send Xen-devel mailing list submissions to
> xen-devel@lists.xen.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel
> or, via email, send a message with subject or body 'help' to
> xen-devel-request@lists.xen.org
>
> You can reach the person managing the list at
> xen-devel-owner@lists.xen.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Xen-devel digest..."
>
>
> Today's Topics:
>
> 1. [PATCH v2 0/2] Xen: Use ioreq-server API (Paul Durrant)
> 2. [PATCH v2 1/2] Add PCI bus listener interface (Paul Durrant)
> 3. Re: [PATCH v4 3/7] [RFC] arm/arm64: introduce is_dma_coherent
> (Will Deacon)
> 4. Error building exynos5.c with debug ?= n (Tamas K Lengyel)
> 5. Re: [PATCH v13 for-xen-4.5 07/21] x86/VPMU: Handle APIC_LVTPC
> accesses (Jan Beulich)
> 6. Re: [PATCH FOR-4.5] xen: arm64: Handle memory banks which are
> not 1GB aligned (Julien Grall)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 13 Oct 2014 13:52:45 +0100
> From: Paul Durrant <paul.durrant@citrix.com>
> To: <qemu-devel@nongnu.org>, <xen-devel@lists.xenproject.org>
> Subject: [Xen-devel] [PATCH v2 0/2] Xen: Use ioreq-server API
> Message-ID:
> <1413204767-39317-1-git-send-email-paul.durrant@citrix.com>
> Content-Type: text/plain
>
> This patch series is v2 of what was the single patch "Xen: Use
> the ioreq-server API when available". The code that adds the
> PCI bus listener is now in patch #1 of this series and the
> remainder of the changes, in patch #2, have been re-worked to
> constrain the #ifdefing to xen_common.h, as requested by
> Stefano.
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 13 Oct 2014 13:52:46 +0100
> From: Paul Durrant <paul.durrant@citrix.com>
> To: <qemu-devel@nongnu.org>, <xen-devel@lists.xenproject.org>
> Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>, Thomas Huth
> <thuth@linux.vnet.ibm.com>, "Michael S. Tsirkin" <
> mst@redhat.com>,
> Christian Borntraeger <borntraeger@de.ibm.com>, Paul Durrant
> <paul.durrant@citrix.com>, Paolo Bonzini <pbonzini@redhat.com
> >,
> Andreas Faerber <afaerber@suse.de>
> Subject: [Xen-devel] [PATCH v2 1/2] Add PCI bus listener interface
> Message-ID:
> <1413204767-39317-2-git-send-email-paul.durrant@citrix.com>
> Content-Type: text/plain
>
> The Xen ioreq-server API, introduced in Xen 4.5, requires that PCI device
> models explicitly register with Xen for config space accesses. This patch
> adds a PCI bus listener interface which can be used by the Xen interface
> code to monitor PCI buses for arrival and departure of devices.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Andreas Faerber <afaerber@suse.de>
> Cc: Thomas Huth <thuth@linux.vnet.ibm.com>
> Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> hw/pci/pci.c | 65
> +++++++++++++++++++++++++++++++++++++++++++++++
> include/hw/pci/pci.h | 9 +++++++
> include/qemu/typedefs.h | 1 +
> 3 files changed, 75 insertions(+)
>
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 6ce75aa..53c955d 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -122,6 +122,66 @@ static uint16_t pci_default_sub_device_id =
> PCI_SUBDEVICE_ID_QEMU;
>
> static QLIST_HEAD(, PCIHostState) pci_host_bridges;
>
> +static QTAILQ_HEAD(pci_listeners, PCIListener) pci_listeners
> + = QTAILQ_HEAD_INITIALIZER(pci_listeners);
> +
> +enum ListenerDirection { Forward, Reverse };
> +
> +#define PCI_LISTENER_CALL(_callback, _direction, _args...) \
> + do { \
> + PCIListener *_listener; \
> + \
> + switch (_direction) { \
> + case Forward: \
> + QTAILQ_FOREACH(_listener, &pci_listeners, link) { \
> + if (_listener->_callback) { \
> + _listener->_callback(_listener, ##_args); \
> + } \
> + } \
> + break; \
> + case Reverse: \
> + QTAILQ_FOREACH_REVERSE(_listener, &pci_listeners, \
> + pci_listeners, link) { \
> + if (_listener->_callback) { \
> + _listener->_callback(_listener, ##_args); \
> + } \
> + } \
> + break; \
> + default: \
> + abort(); \
> + } \
> + } while (0)
> +
> +static int pci_listener_add(DeviceState *dev, void *opaque)
> +{
> + if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
> + PCIDevice *pci_dev = PCI_DEVICE(dev);
> +
> + PCI_LISTENER_CALL(device_add, Forward, pci_dev);
> + }
> +
> + return 0;
> +}
> +
> +void pci_listener_register(PCIListener *listener)
> +{
> + PCIHostState *host;
> +
> + QTAILQ_INSERT_TAIL(&pci_listeners, listener, link);
> +
> + QLIST_FOREACH(host, &pci_host_bridges, next) {
> + PCIBus *bus = host->bus;
> +
> + qbus_walk_children(&bus->qbus, NULL, NULL, pci_listener_add,
> + NULL, NULL);
> + }
> +}
> +
> +void pci_listener_unregister(PCIListener *listener)
> +{
> + QTAILQ_REMOVE(&pci_listeners, listener, link);
> +}
> +
> static int pci_bar(PCIDevice *d, int reg)
> {
> uint8_t type;
> @@ -795,6 +855,8 @@ static void pci_config_free(PCIDevice *pci_dev)
>
> static void do_pci_unregister_device(PCIDevice *pci_dev)
> {
> + PCI_LISTENER_CALL(device_del, Reverse, pci_dev);
> +
> pci_dev->bus->devices[pci_dev->devfn] = NULL;
> pci_config_free(pci_dev);
>
> @@ -878,6 +940,9 @@ static PCIDevice *do_pci_register_device(PCIDevice
> *pci_dev, PCIBus *bus,
> pci_dev->config_write = config_write;
> bus->devices[devfn] = pci_dev;
> pci_dev->version_id = 2; /* Current pci device vmstate version */
> +
> + PCI_LISTENER_CALL(device_add, Forward, pci_dev);
> +
> return pci_dev;
> }
>
> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> index c352c7b..6c21b37 100644
> --- a/include/hw/pci/pci.h
> +++ b/include/hw/pci/pci.h
> @@ -303,6 +303,15 @@ struct PCIDevice {
> MSIVectorPollNotifier msix_vector_poll_notifier;
> };
>
> +struct PCIListener {
> + void (*device_add)(PCIListener *listener, PCIDevice *pci_dev);
> + void (*device_del)(PCIListener *listener, PCIDevice *pci_dev);
> + QTAILQ_ENTRY(PCIListener) link;
> +};
> +
> +void pci_listener_register(PCIListener *listener);
> +void pci_listener_unregister(PCIListener *listener);
> +
> void pci_register_bar(PCIDevice *pci_dev, int region_num,
> uint8_t attr, MemoryRegion *memory);
> void pci_register_vga(PCIDevice *pci_dev, MemoryRegion *mem,
> diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
> index 04df51b..2b974c6 100644
> --- a/include/qemu/typedefs.h
> +++ b/include/qemu/typedefs.h
> @@ -54,6 +54,7 @@ typedef struct PCIHostState PCIHostState;
> typedef struct PCIExpressHost PCIExpressHost;
> typedef struct PCIBus PCIBus;
> typedef struct PCIDevice PCIDevice;
> +typedef struct PCIListener PCIListener;
> typedef struct PCIExpressDevice PCIExpressDevice;
> typedef struct PCIBridge PCIBridge;
> typedef struct PCIEAERMsg PCIEAERMsg;
> --
> 1.7.10.4
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 13 Oct 2014 13:57:25 +0100
> From: Will Deacon <will.deacon@arm.com>
> To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
> "linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
> "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, Catalin
> Marinas
> <Catalin.Marinas@arm.com>, "linux-kernel@vger.kernel.org"
> <linux-kernel@vger.kernel.org>, "david.vrabel@citrix.com"
> <david.vrabel@citrix.com>, "
> linux-arm-kernel@lists.infradead.org"
> <linux-arm-kernel@lists.infradead.org>
> Subject: Re: [Xen-devel] [PATCH v4 3/7] [RFC] arm/arm64: introduce
> is_dma_coherent
> Message-ID: <20141013125725.GA19156@arm.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Oct 13, 2014 at 12:16:14PM +0100, Stefano Stabellini wrote:
> > On Fri, 10 Oct 2014, Stefano Stabellini wrote:
> > > On Fri, 10 Oct 2014, Will Deacon wrote:
> > > > On Fri, Oct 10, 2014 at 12:51:44PM +0100, Stefano Stabellini wrote:
> > > > > Introduce a function to check whether a device is dma coherent.
> > > > >
> > > > > Signed-off-by: Stefano Stabellini <
> stefano.stabellini@eu.citrix.com>
> > > > > CC: linux@arm.linux.org.uk
> > > > > CC: catalin.marinas@arm.com
> > > > > CC: will.deacon@arm.com
> > > > > CC: linux-arm-kernel@lists.infradead.org
> > > > > ---
> > > > > arch/arm/include/asm/dma-mapping.h | 6 ++++++
> > > > > arch/arm64/include/asm/dma-mapping.h | 5 +++++
> > > > > 2 files changed, 11 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/include/asm/dma-mapping.h
> b/arch/arm/include/asm/dma-mapping.h
> > > > > index c45b61a..bededbb 100644
> > > > > --- a/arch/arm/include/asm/dma-mapping.h
> > > > > +++ b/arch/arm/include/asm/dma-mapping.h
> > > > > @@ -126,6 +126,12 @@ static inline int
> set_arch_dma_coherent_ops(struct device *dev)
> > > > > set_dma_ops(dev, &arm_coherent_dma_ops);
> > > > > return 0;
> > > > > }
> > > > > +
> > > > > +static inline bool is_dma_coherent(struct device *dev)
> > > > > +{
> > > > > + return (__generic_dma_ops(dev) == &arm_coherent_dma_ops);
> > > > > +}
> > > >
> > > > Hmm, what about the IOMMU ops?
> > >
> > > Maybe I should check __generic_dma_ops(dev) != &arm_dma_ops?
> > > Do you have any better suggestions?
> >
> > ping?
>
> Without any clear idea about why this is needed or how it's used, I don't
> have any better ideas.
>
> Will
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 13 Oct 2014 14:59:39 +0200
> From: Tamas K Lengyel <tamas.lengyel@zentific.com>
> To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
> Subject: [Xen-devel] Error building exynos5.c with debug ?= n
> Message-ID:
> <CAErYnsgZb1Kyu1=
> Zcsifde69EHqt-GrMTtc2_zEuqEMJ3nPLYQ@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> When attempting to build the latest xen-unstable from git with debug ?= n
> set in Config.mk I get the following error message:
>
> make -f /root/xen/xen/Rules.mk -C platforms built_in.o
> make[5]: Entering directory `/root/xen/xen/arch/arm/platforms'
> gcc -O2 -fomit-frame-pointer -marm -fno-strict-aliasing -std=gnu99 -Wall
> -Wstrict-prototypes -Wdeclaration-after-statement
> -Wno-unused-but-set-variable -Wno-unused-local-typedefs -DNDEBUG
> -I/root/xen/xen/include -fno-stack-protector -fno-exceptions
> -Wnested-externs -msoft-float -mcpu=cortex-a15
> -DGCC_HAS_VISIBILITY_ATTRIBUTE -fno-builtin -fno-common -Werror
> -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include
> /root/xen/xen/include/xen/config.h -nostdinc -DHAS_PASSTHROUGH
> -DHAS_DEVICE_TREE -DHAS_PDX -MMD -MF .vexpress.o.d -c vexpress.c -o
> vexpress.o
> gcc -O2 -fomit-frame-pointer -marm -fno-strict-aliasing -std=gnu99 -Wall
> -Wstrict-prototypes -Wdeclaration-after-statement
> -Wno-unused-but-set-variable -Wno-unused-local-typedefs -DNDEBUG
> -I/root/xen/xen/include -fno-stack-protector -fno-exceptions
> -Wnested-externs -msoft-float -mcpu=cortex-a15
> -DGCC_HAS_VISIBILITY_ATTRIBUTE -fno-builtin -fno-common -Werror
> -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include
> /root/xen/xen/include/xen/config.h -nostdinc -DHAS_PASSTHROUGH
> -DHAS_DEVICE_TREE -DHAS_PDX -MMD -MF .brcm.o.d -c brcm.c -o brcm.o
> gcc -O2 -fomit-frame-pointer -marm -fno-strict-aliasing -std=gnu99 -Wall
> -Wstrict-prototypes -Wdeclaration-after-statement
> -Wno-unused-but-set-variable -Wno-unused-local-typedefs -DNDEBUG
> -I/root/xen/xen/include -fno-stack-protector -fno-exceptions
> -Wnested-externs -msoft-float -mcpu=cortex-a15
> -DGCC_HAS_VISIBILITY_ATTRIBUTE -fno-builtin -fno-common -Werror
> -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include
> /root/xen/xen/include/xen/config.h -nostdinc -DHAS_PASSTHROUGH
> -DHAS_DEVICE_TREE -DHAS_PDX -MMD -MF .exynos5.o.d -c exynos5.c -o exynos5.o
> {standard input}: Assembler messages:
> {standard input}:481: Error: .err encountered
> {standard input}:482: Error: .err encountered
> {standard input}:483: Error: .err encountered
> make[5]: *** [exynos5.o] Error 1
> make[5]: Leaving directory `/root/xen/xen/arch/arm/platforms'
>
> It compiles fine with debug ?= y.
>
> Tamas
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.xen.org/archives/html/xen-devel/attachments/20141013/5a681d4e/attachment.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Mon, 13 Oct 2014 14:02:08 +0100
> From: "Jan Beulich" <JBeulich@suse.com>
> To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
> Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
> andrew.cooper3@citrix.com, tim@xen.org,
> dietmar.hahn@ts.fujitsu.com,
> xen-devel@lists.xen.org, Aravind.Gopalakrishnan@amd.com,
> jun.nakajima@intel.com, dgdegra@tycho.nsa.gov
> Subject: Re: [Xen-devel] [PATCH v13 for-xen-4.5 07/21] x86/VPMU:
> Handle APIC_LVTPC accesses
> Message-ID: <543BE970020000780003E4BD@mail.emea.novell.com>
> Content-Type: text/plain; charset=US-ASCII
>
> >>> On 03.10.14 at 23:40, <boris.ostrovsky@oracle.com> wrote:
> > @@ -706,10 +693,6 @@ static int core2_vpmu_do_interrupt(struct
> cpu_user_regs *regs)
> > return 0;
> > }
> >
> > - /* HW sets the MASK bit when performance counter interrupt occurs*/
> > - vpmu->hw_lapic_lvtpc = apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED;
> > - apic_write_around(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
>
> So why is simply deleting this correct? The comment makes pretty
> clear why it was being done here. All I could see being valid without
> further explanation is the removal of the middle of the three lines.
>
> Jan
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 13 Oct 2014 14:09:10 +0100
> From: Julien Grall <julien.grall@linaro.org>
> To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
> Cc: Roy Franz <roy.franz@linaro.org>, tim@xen.org, Vijay Kilari
> <vijay.kilari@gmail.com>, Suravee Suthikulanit
> <suravee.suthikulpanit@amd.com>,
> stefano.stabellini@eu.citrix.com
> Subject: Re: [Xen-devel] [PATCH FOR-4.5] xen: arm64: Handle memory
> banks which are not 1GB aligned
> Message-ID: <543BCEF6.80800@linaro.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Ian,
>
> On 10/10/2014 03:43 PM, Ian Campbell wrote:
> > The code in the arm64 version of setup_xenheap_mappings was making
> > some very confused attempts to handle this but was bogus.
> >
> > As well as adjusting the mapping to start on a 1GB boundary we also
> > need to account for the offset between the start of the mapping and
> > the actual start of the heap when converting between page pointers,
> > virtual addresses and machine addresses.
> >
> > I preferred to do this by explicitly accounting for the offset rather
> > than adding an offset to the frametable because that approach could
> > potentially waste a large amount of frametable (up to just less than
> > 1GB worth) but also because of issues with converting mfns from
> > outside the regions considered for pdx initialisation (which are not
> > 1GB aligned) back and forth.
> >
> > We already have an idea of the distinction between the start of the
> > direct map and the start of the xenheap in the difference between
> > DIRECTMAP_VIRT_START and XENHEAP_VIRT_START. Until now these were the
> > same thing, but now we change XENHEAP_VIRT_START to point to the
> > actual start of heap not the mapping. Surprisingly there was only one
> > place which was using the conceptually wrong value.
> >
> > Also change xenheap_virt_end to a vaddr_t for consistency.
> >
> > We've been lucky so far that most hardware happens to locate memory
> > on a 1GB boundary (we did have reports of a system with memory at a
> > half gig boundary which exhibited failures which I didn't manage to
> > follow up on successfully). The EFI support has exposed this
> > shortcoming by the way it handles reserved memory, which has a
> > similar effect to having memory non-1GB aligned.
> >
> > arm32 does things differently here due to using a small Xen heap and
> > a demand mapped domain heap, so isn't affected.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
> > Cc: Roy Franz <roy.franz@linaro.org>
> > Cc: Vijay Kilari <vijay.kilari@gmail.com>
> > ---
> > FOR-4.5: This is a bug fix.
>
> Looks good to me:
>
> Reviewed-by: Julien Grall <julien.grall@linaro.org>
>
> Regards,
>
> --
> Julien Grall
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>
> End of Xen-devel Digest, Vol 116, Issue 297
> *******************************************
>
[-- Attachment #1.2: Type: text/html, Size: 26488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 2+ messages in thread