* [PATCH v5 00/22] vITS save/restore
From: Prakash B @ 2017-04-26 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-1-git-send-email-eric.auger@redhat.com>
Verified on Cavium ThunderX platform
Continousily migrated Guest more than 500 times b/w different hosts.
Please feel free to add Tested-by: Prakash, Brahmajyosyula
<Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v2] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
From: Will Deacon @ 2017-04-26 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+sq2Ce2UVi04VtD4KLDsNk2baN1kq_vN2KOrEt9a_cB0gJ0vw@mail.gmail.com>
On Wed, Apr 26, 2017 at 04:13:29PM +0530, Sunil Kovvuri wrote:
> On Wed, Apr 26, 2017 at 3:31 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Hi Sunil,
> >
> > On Tue, Apr 25, 2017 at 03:27:52PM +0530, sunil.kovvuri at gmail.com wrote:
> >> From: Sunil Goutham <sgoutham@cavium.com>
> >>
> >> For software initiated address translation, when domain type is
> >> IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
> >> i.e return the same IOVA as translated address.
> >>
> >> This patch is an extension to Will Deacon's patchset
> >> "Implement SMMU passthrough using the default domain".
> >>
> >> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
> >> ---
> >>
> >> V2
> >> - As per Will's suggestion applied fix to SMMUv3 driver as well.
> >
> > This follows what the AMD driver does, so:
> >
> > Acked-by: Will Deacon <will.deacon@arm.com>
>
> Thanks,
>
> >
> > but I still think that having drivers/net/ethernet/cavium/thunder/nicvf_queues.c
> > poke around with the physical address to get at the struct pages underlying
> > a DMA buffer is really dodgy.
>
> Driver is not dealing with page structures to be precise, just like
> for any other NIC device, driver needs to know the virtual address
> of the packet to where it's DMA'ed, so that SKB if framed and
> handed over to network stack. Due to reasons mentioned below,
> in this driver it's not possible to maintain a list of DMA addresses to
> Virtual address mappings. Hence using IOMMU API, DMA address
> is translated to physical address and finally to virtual address. I don't
> see anything dodgy here.
It's dodgy because you're the only NIC driver using iommu_iova_to_phys
directly and, afaict, the driver could just stash either the struct page
or the virtual address at the point of allocation.
> > Is there no way this can be avoided, perhaps by tracking the pages some other way
>
> I have explained that in the commit message
> --
> Also VNIC doesn't have a seperate receive buffer ring per receive
> queue, so there is no 1:1 descriptor index matching between CQE_RX
> and the index in buffer ring from where a buffer has been used for
> DMA'ing. Unlike other NICs, here it's not possible to maintain dma
> address to virt address mappings within the driver. This leaves us
> no other choice but to use IOMMU's IOVA address conversion API to
> get buffer's virtual address which can be given to network stack
> for processing.
> --
>
> >(although I don't understand why you're having to mess with the page reference
> >counts to start with)?
> Not sure why you say it's a mess, adjusting page reference counts is quite
> common if you check other NIC drivers. On ARM64 especially when using
> 64KB pages, if we have only one packet buffer for each page then we
> will have to set aside a whole lot of memory which sometimes is not possible
> on embedded platforms. Hence multiple pkt buffers per page, and page reference
> is set accordingly.
I wasn't saying that was a mess, I was just saying that I didn't understand
why you mess (verb) with the page reference counts (my ignorance of the
network layer). The code that I think is a mess is:
phys_addr = nicvf_iova_to_phys(nic, buf_addr);
[...]
put_page(virt_to_page(phys_to_virt(phys_addr)));
because:
(a) You have the information you need at allocation time, but you've
failed to record that and are trying to use the IOMMU API to
reconstruct the CPU virtual address
(b) When there isn't an IOMMU present, you assume that bus addresses ==
physical addresses
(c) You assume that the DMA buffer is mapped in the linear mapping
that's probably all true for ThunderX/arm64, but it's generally not portable
or reliable code. If you could get a handle to the struct page that you
allocated in the first place, then you could use page_address to get its
virtual address instead of having to go via the physical address.
Will
^ permalink raw reply
* [PATCH v5 22/22] KVM: arm64: vgic-v3: KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES
From: Prakash B @ 2017-04-26 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-23-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> This patch adds a new attribute to GICV3 KVM device
> KVM_DEV_ARM_VGIC_GRP_CTRL group. This Allows the userspace to
> flush all GICR pending tables into guest RAM. At the moment
> we do not offer any restore control as the sync is implicit.
>
> As we need the PENDBASER_ADDRESS() in vgic-v3, let's move its
> definition in the irqchip header. We restore the full length
> of the field, ie [51:16]. Same for PROPBASER_ADDRESS with full
> field length of [51:12].
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 21/22] KVM: arm64: vgic-its: Fix pending table sync
From: Prakash B @ 2017-04-26 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-22-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> In its_sync_lpi_pending_table() we currently ignore the
> target_vcpu of the LPIs. We sync the pending bit found in
> the vcpu pending table even if the LPI is not targeting it.
>
> Also in vgic_its_cmd_handle_invall() we are supposed to
> read the config table data for the LPIs associated to the
> collection ID. At the moment we refresh all LPI config
> information.
>
> This patch passes a vpcu to vgic_copy_lpi_list() so that
> this latter returns a snapshot of the LPIs targeting this
> CPU and only those.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 20/22] KVM: arm64: vgic-its: Device table save/restore
From: Prakash B @ 2017-04-26 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-21-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> This patch saves the device table entries into guest RAM.
> Both flat table and 2 stage tables are supported. DeviceId
> indexing is used.
>
> For each device listed in the device table, we also save
> the translation table using the vgic_its_save/restore_itt
> routines.
>
> On restore, devices are re-allocated and their ite are
> re-built.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 19/22] KVM: arm64: vgic-its: ITT save and restore
From: Prakash B @ 2017-04-26 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-20-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> Introduce routines to save and restore device ITT and their
> interrupt table entries (ITE).
>
> The routines will be called on device table save and
> restore. They will become static in subsequent patches.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 18/22] KVM: arm64: vgic-its: vgic_its_check_id returns the entry's GPA
From: Prakash B @ 2017-04-26 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-19-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> As vgic_its_check_id() computes the device/collection entry's
> GPA, let's return it so that new callers can retrieve it easily.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 17/22] KVM: arm64: vgic-its: Collection table save/restore
From: Prakash B @ 2017-04-26 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-18-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> The save path copies the collection entries into guest RAM
> at the GPA specified in the BASER register. This obviously
> requires the BASER to be set. The last written element is a
> dummy collection table entry.
>
> We do not index by collection ID as the collection entry
> can fit into 8 bytes while containing the collection ID.
>
> On restore path we re-allocate the collection objects.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 16/22] KVM: arm64: vgic-its: Add infrastructure for table lookup
From: Prakash B @ 2017-04-26 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-17-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> Add a generic lookup_table() helper whose role consists in
> scanning a contiguous table located in guest RAM and applying
> a callback on each entry. Entries can be handled as linked lists
> since the callback may return an offset to the next entry and
> also tell that an entry is the last one.
>
> Helper functions also are added to compute the device/event ID
> offset to the next DTE/ITE.
>
> compute_next_devid_offset, compute_next_eventid_offset and
> lookup_table will become static in subsequent patches
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v2 2/2] arm64: module: split core and init PLT sections
From: Catalin Marinas @ 2017-04-26 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1487715177-30790-3-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Feb 21, 2017 at 10:12:57PM +0000, Ard Biesheuvel wrote:
> The arm64 module PLT code allocates all PLT entries in a single core
> section, since the overhead of having a separate init PLT section is
> not justified by the small number of PLT entries usually required for
> init code.
>
> However, the core and init module regions are allocated independently,
> and there is a corner case where the core region may be allocated from
> the VMALLOC region if the dedicated module region is exhausted, but the
> init region, being much smaller, can still be allocated from the module
> region. This leads to relocation failures if the distance between those
> regions exceeds 128 MB. (In fact, this corner case is highly unlikely to
> occur on arm64, but the issue has been observed on ARM, whose module
> region is much smaller).
>
> So split the core and init PLT regions, and name the latter ".init.plt"
> so it gets allocated along with (and sufficiently close to) the .init
> sections that it serves. Also, given that init PLT entries may need to
> be emitted for branches that target the core module, modify the logic
> that disregards defined symbols to only disregard symbols that are
> defined in the same section as the relocated branch instruction.
>
> Since there may now be two PLT entries associated with each entry in
> the symbol table, we can no longer hijack the symbol::st_size fields
> to record the addresses of PLT entries as we emit them for zero-addend
> relocations. So instead, perform an explicit comparison to check for
> duplicate entries.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
I forgot about this patch. I'll queue it for 4.12. Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v5 15/22] KVM: arm64: vgic-its: vgic_its_alloc_ite/device
From: Prakash B @ 2017-04-26 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-16-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> Add two new helpers to allocate an its ite and an its device.
> This will avoid duplication on restore path.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 14/22] KVM: arm64: vgic-its: KVM_DEV_ARM_ITS_SAVE/RESTORE_TABLES
From: Prakash B @ 2017-04-26 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-15-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> Introduce new attributes in KVM_DEV_ARM_VGIC_GRP_CTRL group:
> - KVM_DEV_ARM_ITS_SAVE_TABLES: saves the ITS tables into guest RAM
> - KVM_DEV_ARM_ITS_RESTORE_TABLES: restores them into VGIC internal
> structures.
>
> We hold the vcpus lock during the save and restore to make
> sure no vcpu is running.
>
> At this stage the functionality is not yet implemented. Only
> the skeleton is put in place.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 13/22] KVM: arm64: vgic-its: Check the device id matches TYPER DEVBITS range
From: Prakash B @ 2017-04-26 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-14-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> On MAPD we currently check the device id can be stored in the device table.
> Let's first check it can be encoded within the range defined by TYPER
> DEVBITS.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 12/22] KVM: arm64: vgic-its: Interpret MAPD ITT_addr field
From: Prakash B @ 2017-04-26 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-13-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> Up to now the MAPD ITT_addr had been ignored. We will need it
> for save/restore. Let's record it in the its_device struct.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 11/22] KVM: arm64: vgic-its: Interpret MAPD Size field and check related errors
From: Prakash B @ 2017-04-26 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-12-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> Up to now the MAPD's ITT size field has been ignored. It encodes
> the number of eventid bit minus 1. It should be used to check
> the eventid when a MAPTI command is issued on a device. Let's
> store the number of eventid bits in the its_device and do the
> check on MAPTI. Also make sure the ITT size field does
> not exceed the GITS_TYPER IDBITS field.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 10/22] KVM: arm64: vgic-its: Implement vgic_mmio_uaccess_write_its_iidr
From: Prakash B @ 2017-04-26 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-11-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> The GITS_IIDR revision field is used to encode the migration ABI
> revision. So we need to restore it to check the table layout is
> readable by the destination.
>
> By writing the IIDR, userspace thus force the ABI revision to be
> used and this msut be less or equal than the max revision KVM supports.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 09/22] KVM: arm64: vgic-its: Introduce migration ABI infrastructure
From: Prakash B @ 2017-04-26 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-10-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> We plan to support different migration ABIs, ie. characterizing
> the ITS table layout format in guest RAM. Typically a new ABI will
> be needed if vLPIs get supported for nested use case.
>
> So let's introduce an array of supported ABIs (at the moment a single
> ABI is supported though). The following characteristics are foreseen
> to vary with the ABI: size of table entries, save/restore operation.
>
> By default the MAX_ABI_REV is applied on its creation. In subsequent
> patches we will introduce a way for the userspace to change the ABI
> in use.
>
> The entry sizes now are set according to the ABI version and not
> hardcoded anymore.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [patch] propagating controls in libv4l2 was Re: support autofocus / autogain in libv4l2
From: Mauro Carvalho Chehab @ 2017-04-26 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426105300.GA857@amd>
Em Wed, 26 Apr 2017 12:53:00 +0200
Pavel Machek <pavel@ucw.cz> escreveu:
> Hi!
>
> > > > IMO, the best place for autofocus is at libv4l2. Putting it on a
> > > > separate "video server" application looks really weird for me.
> > >
> > > Well... let me see. libraries are quite limited -- it is hard to open
> > > files, or use threads/have custom main loop. It may be useful to
> > > switch resolutions -- do autofocus/autogain at lower resolution, then
> > > switch to high one for taking picture. It would be good to have that
> > > in "system" code, but I'm not at all sure libv4l2 design will allow
> > > that.
> >
> > I don't see why it would be hard to open files or have threads inside
> > a library. There are several libraries that do that already, specially
> > the ones designed to be used on multimidia apps.
>
> Well, This is what the libv4l2 says:
>
> This file implements libv4l2, which offers v4l2_ prefixed versions
> of
> open/close/etc. The API is 100% the same as directly opening
> /dev/videoX
> using regular open/close/etc, the big difference is that format
> conversion
>
> but if I open additional files in v4l2_open(), API is no longer the
> same, as unix open() is defined to open just one file descriptor.
>
> Now. There is autogain support in libv4lconvert, but it expects to use
> same fd for camera and for the gain... which does not work with
> subdevs.
>
> Of course, opening subdevs by name like this is not really
> acceptable. But can you suggest a method that is?
>
> Thanks,
> Pavel
>
> commit 4cf9d10ead014c0db25452e4bb9cd144632407c3
> Author: Pavel <pavel@ucw.cz>
> Date: Wed Apr 26 11:38:04 2017 +0200
>
> Add subdevices.
>
> diff --git a/lib/libv4l2/libv4l2-priv.h b/lib/libv4l2/libv4l2-priv.h
> index 343db5e..a6bc48e 100644
> --- a/lib/libv4l2/libv4l2-priv.h
> +++ b/lib/libv4l2/libv4l2-priv.h
> @@ -26,6 +26,7 @@
> #include "../libv4lconvert/libv4lsyscall-priv.h"
>
> #define V4L2_MAX_DEVICES 16
> +#define V4L2_MAX_SUBDEVS 8
Isn't it a short number?
> /* Warning when making this larger the frame_queued and frame_mapped members of
> the v4l2_dev_info struct can no longer be a bitfield, so the code needs to
> be adjusted! */
> @@ -104,6 +105,7 @@ struct v4l2_dev_info {
> void *plugin_library;
> void *dev_ops_priv;
> const struct libv4l_dev_ops *dev_ops;
> + int subdev_fds[V4L2_MAX_SUBDEVS];
> };
>
> /* From v4l2-plugin.c */
> diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
> index 0ba0a88..edc9642 100644
> --- a/lib/libv4l2/libv4l2.c
> +++ b/lib/libv4l2/libv4l2.c
> @@ -1,3 +1,4 @@
> +/* -*- c-file-style: "linux" -*- */
No emacs comments, please.
> /*
> # (C) 2008 Hans de Goede <hdegoede@redhat.com>
>
> @@ -789,18 +790,25 @@ no_capture:
>
> /* Note we always tell v4lconvert to optimize src fmt selection for
> our default fps, the only exception is the app explicitly selecting
> - a fram erate using the S_PARM ioctl after a S_FMT */
> + a frame rate using the S_PARM ioctl after a S_FMT */
> if (devices[index].convert)
> v4lconvert_set_fps(devices[index].convert, V4L2_DEFAULT_FPS);
> v4l2_update_fps(index, &parm);
>
> + devices[index].subdev_fds[0] = SYS_OPEN("/dev/video_sensor", O_RDWR, 0);
> + devices[index].subdev_fds[1] = SYS_OPEN("/dev/video_focus", O_RDWR, 0);
> + devices[index].subdev_fds[2] = -1;
Hardcoding names here is not a good idea. Ideally, it should open
the MC, using the newgen API, and parse the media graph.
The problem is that, even with newgen API, without the properties API
you likely won't be able to write a generic parser. So, we need a
plugin specific for OMAP3 (or at least some database that would teach
a generic plugin about OMAP3 specifics).
I guess that the approach that Jacek was taken were very close to what
a generic plugin would need:
https://lwn.net/Articles/619449/
The last version of his patch set is here:
https://patchwork.linuxtv.org/patch/37496/
I didn't review his patchset, but from what I saw, Sakari is the one
that found some issues on v7.1 patchset.
Sakari,
Could you shed us a light about why this patchset was not merged?
Are there anything really bad at the code, or just minor issues that
could be fixed later?
If it is the last case, perhaps we could merge the code, if this
would make easier for Pavel to work on a N9 solution using the
same approach.
Thanks,
Mauro
^ permalink raw reply
* [PATCH v5 08/22] KVM: arm64: vgic-its: Implement vgic_mmio_uaccess_write_its_creadr
From: Prakash B @ 2017-04-26 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-9-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> GITS_CREADR needs to be restored so let's implement the associated
> uaccess_write_its callback. The write only is allowed if the its
> is disabled.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 07/22] KVM: arm64: vgic-its: Implement vgic_its_has_attr_regs and attr_regs_access
From: Prakash B @ 2017-04-26 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-8-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> This patch implements vgic_its_has_attr_regs and vgic_its_attr_regs_access
> upon the MMIO framework. VGIC ITS KVM device KVM_DEV_ARM_VGIC_GRP_ITS_REGS
> group becomes functional.
>
> At least GITS_CREADR and GITS_IIDR require to differentiate a guest write
> action from a user access. As such let's introduce a new uaccess_its_write
> vgic_register_region callback.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 06/22] KVM: arm/arm64: vgic: expose (un)lock_all_vcpus
From: Prakash B @ 2017-04-26 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-7-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> We need to use those helpers in vgic-its.c so let's
> expose them in the private vgic header.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 05/22] KVM: arm64: vgic-its: KVM_DEV_ARM_VGIC_GRP_ITS_REGS group
From: Prakash B @ 2017-04-26 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-6-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> The ITS KVM device exposes a new KVM_DEV_ARM_VGIC_GRP_ITS_REGS
> group which allows the userspace to save/restore ITS registers.
>
> At this stage the get/set/has operations are not yet implemented.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 04/22] arm/arm64: vgic: turn vgic_find_mmio_region into public
From: Prakash B @ 2017-04-26 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-5-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> We plan to use vgic_find_mmio_region in vgic-its.c so let's
> turn it into a public function.
>
> Also let's take the opportunity to rename the region parameter
> into regions to emphasize this latter is an array of regions.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH v5 03/22] KVM: arm/arm64: vgic-its: rename itte into ite
From: Prakash B @ 2017-04-26 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-4-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 3:45 PM, Eric Auger <eric.auger@redhat.com> wrote:
> The actual abbreviation for the interrupt translation table entry
> is ITE. Let's rename all itte instances by ite.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Prakash, Brahmajyosyula <Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH 0/9] ARM: dts: renesas: update PFC node name to pin-controller
From: Geert Uytterhoeven @ 2017-04-26 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100538.22060-1-horms+renesas@verge.net.au>
Hi Simon,
On Wed, Apr 26, 2017 at 12:05 PM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> The device trees for Renesas SoCs use either pfc or pin-controller as the
> node name for the PFC device. This patch is intended to take a step towards
> unifying the node name used as pin-controller which appears to be the more
> generic of the two and thus more in keeping with the DT specs.
>
> My analysis is that this is a user-visible change to the extent that kernel
> logs, and sysfs entries change from XXX.pfc and pfc at XXX to
> XXX.pin-controller and pin-controller at XXX.
>
> Boot tested on:
> r8a73a4/ape6evm
> r8a7740/armadillo800evb
> r8a7778/bockw
> r8a7790/lager
> r8a7791/koelsch
> r8a7791/porter
> r8a7793/gose
> sh73a9/kzm9g
>
> Not tested on (due to lack of hw access):
> evm2/kzm9d
> r8a7789/marzen
>
> Simon Horman (9):
For the whole series:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox