search for: iomem

Add support for mapping hardware io memory into domains via domain config files. The syntax is iomem=[PAGE,NUM_PAGES] Signed off by Matthew Fioravante: matthew.fioravante@jhuapl.edu --- Changes from previous * Rebased onto latest xen-unstable * Rewrote the feature to mimic the style used by iports and irqs in current libxl * Updated xl.cfg manpage * removed the redundant "allow" field,...

...o.c b/drivers/gpu/drm/nouveau/nv50_evo.c index 0f53416..0483cbd 100644 --- a/drivers/gpu/drm/nouveau/nv50_evo.c +++ b/drivers/gpu/drm/nouveau/nv50_evo.c @@ -33,17 +33,22 @@ #include <subdev/timer.h> #include <subdev/fb.h> +struct evo_object { + struct nouveau_object parent; + void __iomem *iomem; +}; + static u32 nv50_evo_rd32(struct nouveau_object *object, u32 addr) { - void __iomem *iomem = object->oclass->ofuncs->rd08; + void __iomem *iomem = ((struct evo_object *)object)->iomem; return ioread32_native(iomem + addr); } static void nv50_evo_wr32(struct nouvea...

It was decided during xen patch review that xen map the iomem transparently, so remove xen_set_clr_mmio_pvh_pte() and the sub hypercall PHYSDEVOP_map_iomem. --- arch/x86/xen/mmu.c | 14 -------------- arch/x86/xen/setup.c | 16 ++++------------ include/xen/interface/physdev.h | 10 ---------- 3 files changed, 4 insertions(+), 3...

...ns(+), 82 deletions(-) diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c index e70feda..de7f249 100644 --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -664,42 +664,47 @@ static int irq_has_perm(struct domain *d, uint8_t pirq, uint8_t access) return rc; } -static int iomem_has_perm(struct domain *d, unsigned long mfn, uint8_t access) -{ +struct iomem_has_perm_data { + struct domain_security_struct *ssec, *tsec; u32 perm; - u32 rsid; - int rc = -EPERM; +}; - struct domain_security_struct *ssec, *tsec; +static int _iomem_has_perm(void *v, u32 sid, un...

...rdinary DIMM - e.g., >>> memory managed by virtio-mem can have holes inside added memory resource, >>> which should not be touched, especially for writing. >>> >>> Let's expose that memory as "System RAM (driver managed)" e.g., via >>> /pro/iomem. >>> >>> We don't have to worry about firmware_map_remove() on the removal path. >>> If there is no entry, it will simply return with -EINVAL. >>> >>> [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap >>> >&gt...

...led in the xend-config.sxp / xl.conf (one system using xm, another xl) xen command line: placeholder xsave=0 iommu=0 console=vga,com2 com2=115200,8n1 dom0_mem=max:6144m kernel command line: root=/dev/loop0 ro console=tty1 console=hvc0 earlyprintk=xen nomodeset noselfballooning Examining /proc/iomem does show that the dom0 memory allocation is actually 64kb short of 6144Mb: cat /proc/iomem | grep System\ RAM 00010000-0009bfff : System RAM [573440 bytes] 00100000-cb2dffff : System RAM [3407740928 bytes] 100000000-1b4d83fff : System RAM [3034071040 bytes] Total system ram: 644238...

...docs/man/xl.cfg.pod.5 index 013270d..428da21 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g. C<2f8-2ff> It is recommended to use this option only for trusted VMs under administrator control. +=item B<iomem=[ "IOMEM_START,NUM_PAGES", "IOMEM_START,NUM_PAGES", ... ]> + +Allow guest to access specific hardware I/O memory pages. B<IOMEM_START> +is a physical page number. B<NUM_PAGES> is the number +of pages beginning with B<START_PAGE> to allow access. Both values...

...#39;volatile' generally > makes sense, at least for the implementations that do a plain pointer > dereference (probably none of the ones in question here). > > In case of readl/writel, this is what we do in asm-generic: > > static inline u32 __raw_readl(const volatile void __iomem *addr) > { > return *(const volatile u32 __force *)addr; > } SuperH is another example: 1. ioread8_rep(void __iomem *addr, void *dst, unsigned long count) calls mmio_insb() 2. static inline void mmio_insb(void __iomem *addr, u8 *dst, int count) calls __raw_readb() 3. #defi...

...mory could behave differently than an ordinary DIMM - e.g., > memory managed by virtio-mem can have holes inside added memory resource, > which should not be touched, especially for writing. > > Let's expose that memory as "System RAM (driver managed)" e.g., via > /pro/iomem. > > We don't have to worry about firmware_map_remove() on the removal path. > If there is no entry, it will simply return with -EINVAL. > > [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap > > Cc: Andrew Morton <akpm at linux-foundation....

...mory could behave differently than an ordinary DIMM - e.g., > memory managed by virtio-mem can have holes inside added memory resource, > which should not be touched, especially for writing. > > Let's expose that memory as "System RAM (driver managed)" e.g., via > /pro/iomem. > > We don't have to worry about firmware_map_remove() on the removal path. > If there is no entry, it will simply return with -EINVAL. > > [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap > > Cc: Andrew Morton <akpm at linux-foundation....

...e of the few places in which 'volatile' generally makes sense, at least for the implementations that do a plain pointer dereference (probably none of the ones in question here). In case of readl/writel, this is what we do in asm-generic: static inline u32 __raw_readl(const volatile void __iomem *addr) { return *(const volatile u32 __force *)addr; } The __force-cast that removes the __iomem here also means that the 'volatile' keyword could be dropped from the argument list, as it has no real effect any more, but then there are a few drivers that mark their iomem pointers a...

...6 18:32:05 virt kernel: update mother board BIOS or consider utilizing one of Jul 6 18:32:05 virt kernel: the SAFE mode kernel options (acpi, apic etc) Jul 6 18:32:05 virt kernel: Determine the configuration status Now I tried a pvops dom0 kernel and suddenly got "grant_table.c:350:d0 Iomem mapping not permitted ffffffffffffffff" log lines instead of crashes of the whole machine. Any ideas? Andreas _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

Hi Keir, Some device have I/O space but no mem space so checking iomem to grant privileges to DomUs is not enough. Please apply this fix to unstable and xen-3.3-testing. From: Manuel Bouyer <bouyer@netbsd.org> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Karl-Ha...

...;>>>>> >>>>>>> Also, now that I know that esp. kexec-tools already don't consider >>>>>>> dax/kmem memory properly (memory will not get dumped via kdump) and >>>>>>> won't really suffer from a name change in /proc/iomem, I will go back to >>>>>>> the MHP_DRIVER_MANAGED approach and >>>>>>> 1. Don't create firmware memmap entries >>>>>>> 2. Name the resource "System RAM (driver managed)" >>>>>>> 3. Flag the resource vi...

...;>>>>> >>>>>>> Also, now that I know that esp. kexec-tools already don't consider >>>>>>> dax/kmem memory properly (memory will not get dumped via kdump) and >>>>>>> won't really suffer from a name change in /proc/iomem, I will go back to >>>>>>> the MHP_DRIVER_MANAGED approach and >>>>>>> 1. Don't create firmware memmap entries >>>>>>> 2. Name the resource "System RAM (driver managed)" >>>>>>> 3. Flag the resource vi...

...;> patch description. >>>>> >>>>> Also, now that I know that esp. kexec-tools already don't consider >>>>> dax/kmem memory properly (memory will not get dumped via kdump) and >>>>> won't really suffer from a name change in /proc/iomem, I will go back to >>>>> the MHP_DRIVER_MANAGED approach and >>>>> 1. Don't create firmware memmap entries >>>>> 2. Name the resource "System RAM (driver managed)" >>>>> 3. Flag the resource via something like IORESOURCE_MEM_...

...;> patch description. >>>>> >>>>> Also, now that I know that esp. kexec-tools already don't consider >>>>> dax/kmem memory properly (memory will not get dumped via kdump) and >>>>> won't really suffer from a name change in /proc/iomem, I will go back to >>>>> the MHP_DRIVER_MANAGED approach and >>>>> 1. Don't create firmware memmap entries >>>>> 2. Name the resource "System RAM (driver managed)" >>>>> 3. Flag the resource via something like IORESOURCE_MEM_...

...t;>>>>>>>> Also, now that I know that esp. kexec-tools already don't consider >>>>>>>>> dax/kmem memory properly (memory will not get dumped via kdump) and >>>>>>>>> won't really suffer from a name change in /proc/iomem, I will go back to >>>>>>>>> the MHP_DRIVER_MANAGED approach and >>>>>>>>> 1. Don't create firmware memmap entries >>>>>>>>> 2. Name the resource "System RAM (driver managed)" >>>>>>>...

...t;>>>>>>>> Also, now that I know that esp. kexec-tools already don't consider >>>>>>>>> dax/kmem memory properly (memory will not get dumped via kdump) and >>>>>>>>> won't really suffer from a name change in /proc/iomem, I will go back to >>>>>>>>> the MHP_DRIVER_MANAGED approach and >>>>>>>>> 1. Don't create firmware memmap entries >>>>>>>>> 2. Name the resource "System RAM (driver managed)" >>>>>>>...

...al memmap for a kexec kernel (loaded via kexec_load()). The memory will be considered initial System RAM by the kexec kernel. We should let the kexec kernel decide how to use that memory - just as we do during an ordinary reboot. Before configuring the namespace: [root at localhost ~]# cat /proc/iomem ... 140000000-33fffffff : Persistent Memory 140000000-33fffffff : namespace0.0 3280000000-32ffffffff : PCI Bus 0000:00 After configuring the namespace: [root at localhost ~]# cat /proc/iomem ... 140000000-33fffffff : Persistent Memory 140000000-1481fffff : namespace0.0 148200000-33f...