* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Gabriele Paoloni @ 2016-11-09 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109135453.2e5402bd@lxorguk.ukuu.org.uk>
> -----Original Message-----
> From: One Thousand Gnomes [mailto:gnomes at lxorguk.ukuu.org.uk]
> Sent: 09 November 2016 13:55
> To: Arnd Bergmann
> Cc: Mark Rutland; Yuanzhichang; catalin.marinas at arm.com;
> will.deacon at arm.com; robh+dt at kernel.org; bhelgaas at google.com;
> olof at lixom.net; linux-arm-kernel at lists.infradead.org;
> lorenzo.pieralisi at arm.com; linux-kernel at vger.kernel.org; Linuxarm;
> devicetree at vger.kernel.org; linux-pci at vger.kernel.org; linux-
> serial at vger.kernel.org; minyard at acm.org; benh at kernel.crashing.org;
> liviu.dudau at arm.com; zourongrong at gmail.com; John Garry; Gabriele
> Paoloni; zhichang.yuan02 at gmail.com; kantyzc at 163.com; xuwei (O);
> marc.zyngier at arm.com
> Subject: Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for
> special ISA
>
> > I think it is a relatively safe assumption that there is only one
> > ISA bridge. A lot of old drivers hardcode PIO or memory addresses
>
> It's not a safe assumption for x86 at least. There are a few systems
> with
> multiple ISA busses particularly older laptops with a docking station.
Mmmm right...now the point is that this kind of special devices appearing
as a special ISA bus will probably never appear on x86 platforms (I guess).
So maybe it is a safe assumption because of this...?
Thanks
Gab
>
> > when talking to an ISA device, so having multiple instances is
> > already problematic.
>
> PCMCIA devices handle it themselves so are ok. I'm not clear how the
> dual
> PIIX4 configuration used in the older IBM laptop docks actually worked
> so
> I assume the transaction went out of both bridges and providing one of
> them responded the other kept silent as you simply stuffed the card
> into
> the dock and it worked.
>
> Alan
^ permalink raw reply
* RE: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Gabriele Paoloni @ 2016-11-09 14:51 UTC (permalink / raw)
To: One Thousand Gnomes, Arnd Bergmann
Cc: Mark Rutland, Yuanzhichang,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linuxarm,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
minyard-HInyCGIudOg@public.gmane.org, benh-XVmvHMARGAQRh2imMr4xaA
In-Reply-To: <20161109135453.2e5402bd-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
> -----Original Message-----
> From: One Thousand Gnomes [mailto:gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org]
> Sent: 09 November 2016 13:55
> To: Arnd Bergmann
> Cc: Mark Rutland; Yuanzhichang; catalin.marinas-5wv7dgnIgG8@public.gmane.org;
> will.deacon-5wv7dgnIgG8@public.gmane.org; robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org;
> olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm;
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; minyard-HInyCGIudOg@public.gmane.org; benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org;
> liviu.dudau-5wv7dgnIgG8@public.gmane.org; zourongrong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; John Garry; Gabriele
> Paoloni; zhichang.yuan02-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; kantyzc-9Onoh4P/yGk@public.gmane.org; xuwei (O);
> marc.zyngier-5wv7dgnIgG8@public.gmane.org
> Subject: Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for
> special ISA
>
> > I think it is a relatively safe assumption that there is only one
> > ISA bridge. A lot of old drivers hardcode PIO or memory addresses
>
> It's not a safe assumption for x86 at least. There are a few systems
> with
> multiple ISA busses particularly older laptops with a docking station.
Mmmm right...now the point is that this kind of special devices appearing
as a special ISA bus will probably never appear on x86 platforms (I guess).
So maybe it is a safe assumption because of this...?
Thanks
Gab
>
> > when talking to an ISA device, so having multiple instances is
> > already problematic.
>
> PCMCIA devices handle it themselves so are ok. I'm not clear how the
> dual
> PIIX4 configuration used in the older IBM laptop docks actually worked
> so
> I assume the transaction went out of both bridges and providing one of
> them responded the other kept silent as you simply stuffed the card
> into
> the dock and it worked.
>
> Alan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Gabriele Paoloni @ 2016-11-09 14:51 UTC (permalink / raw)
To: One Thousand Gnomes, Arnd Bergmann
Cc: Mark Rutland, Yuanzhichang, catalin.marinas@arm.com,
will.deacon@arm.com, robh+dt@kernel.org, bhelgaas@google.com,
olof@lixom.net, linux-arm-kernel@lists.infradead.org,
lorenzo.pieralisi@arm.com, linux-kernel@vger.kernel.org, Linuxarm,
devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
linux-serial@vger.kernel.org, minyard@acm.org,
benh@kernel.crashing.org, liviu.dudau@arm.com,
zourongrong@gmail.com, John Garry, zhichang.yuan02@gmail.com,
kantyzc@163.com, xuwei (O), marc.zyngier@arm.com
In-Reply-To: <20161109135453.2e5402bd@lxorguk.ukuu.org.uk>
> -----Original Message-----
> From: One Thousand Gnomes [mailto:gnomes@lxorguk.ukuu.org.uk]
> Sent: 09 November 2016 13:55
> To: Arnd Bergmann
> Cc: Mark Rutland; Yuanzhichang; catalin.marinas@arm.com;
> will.deacon@arm.com; robh+dt@kernel.org; bhelgaas@google.com;
> olof@lixom.net; linux-arm-kernel@lists.infradead.org;
> lorenzo.pieralisi@arm.com; linux-kernel@vger.kernel.org; Linuxarm;
> devicetree@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> serial@vger.kernel.org; minyard@acm.org; benh@kernel.crashing.org;
> liviu.dudau@arm.com; zourongrong@gmail.com; John Garry; Gabriele
> Paoloni; zhichang.yuan02@gmail.com; kantyzc@163.com; xuwei (O);
> marc.zyngier@arm.com
> Subject: Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for
> special ISA
>
> > I think it is a relatively safe assumption that there is only one
> > ISA bridge. A lot of old drivers hardcode PIO or memory addresses
>
> It's not a safe assumption for x86 at least. There are a few systems
> with
> multiple ISA busses particularly older laptops with a docking station.
Mmmm right...now the point is that this kind of special devices appearing
as a special ISA bus will probably never appear on x86 platforms (I guess).
So maybe it is a safe assumption because of this...?
Thanks
Gab
>
> > when talking to an ISA device, so having multiple instances is
> > already problematic.
>
> PCMCIA devices handle it themselves so are ok. I'm not clear how the
> dual
> PIIX4 configuration used in the older IBM laptop docks actually worked
> so
> I assume the transaction went out of both bridges and providing one of
> them responded the other kept silent as you simply stuffed the card
> into
> the dock and it worked.
>
> Alan
^ permalink raw reply
* Re: [PATCH v4 1/4] btrfs-progs: utils: Introduce function to escape characters
From: David Sterba @ 2016-11-09 14:50 UTC (permalink / raw)
To: Qu Wenruo; +Cc: dsterba, linux-btrfs
In-Reply-To: <58be30ff-591c-6a96-0f48-ea3ba8b8c76d@cn.fujitsu.com>
On Tue, Nov 08, 2016 at 08:33:25AM +0800, Qu Wenruo wrote:
> While still some small comment.
> + if (!isprint(c)) {
> + printf("\\%c%c%c",
> + '0' + ((c & 0300) >> 6),
> + '0' + ((c & 070) >> 3),
> + '0' + (c & 07));
>
> For non-printable chars, isn't it more common to print it as hex other
> than octal?
Ok, hex would be better.
^ permalink raw reply
* Re: disable hugepages
From: Olivier Matz @ 2016-11-09 14:50 UTC (permalink / raw)
To: Keren Hochman, Christian Ehrhardt; +Cc: dev
In-Reply-To: <CAJq3SQ7r4e_Dr1wvwPYmiECWASEvAwvZomH4x6o1MFo35JQVXg@mail.gmail.com>
Hi Keren,
On 11/09/2016 03:40 PM, Keren Hochman wrote:
> On Wed, Nov 9, 2016 at 3:40 PM, Christian Ehrhardt <
> christian.ehrhardt@canonical.com> wrote:
>
>>
>> On Wed, Nov 9, 2016 at 1:55 PM, Keren Hochman <
>> keren.hochman@lightcyber.com> wrote:
>>
>>> how can I create mempool without hugepages?My application is running on a
>>> pcap file so no huge pages is needed ?
>>>
>>
>> Not sure if that is what you really want (Debug use only), but in general
>> no-huge is available as EAL arg
>>
>> From http://pktgen.readthedocs.io/en/latest/usage_eal.html :
>>
>> EAL options for DEBUG use only:
>> --no-huge : Use malloc instead of hugetlbfs
>>
> I need this option only for testing. How can I use rte_mempool_create if I
> use --no-huge?
When using --no-huge, the dpdk libraries (including mempool) allocate
its memory in standard memory. Just keep in mind the physical addresses
will be wrong, so this memory cannot be given to hw devices.
Regards,
Olivier
^ permalink raw reply
* Re: [PATCH v2] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()
From: Lee Jones @ 2016-11-09 14:52 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Thierry Reding, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-pwm, linux-kernel, Fabio Estevam, Fabio Estevam,
linux-fbdev, Liu Ying
In-Reply-To: <20161108232525.639ea49f@jawa>
On Tue, 08 Nov 2016, Lukasz Majewski wrote:
> Dear All,
>
> > The commit a55944ca82d2 ("backlight: update bd state & fb_blank
> > properties when necessary") has posed some extra restrictions on
> > blanking and unblanking frame buffer device.
> >
> > Unfortunately, pwm_bl driver's probe did not initialize members of
> > struct backlight_device necessary for further blank/unblank operation.
> >
> > This code in case of initial unblank of backlight device (default
> > behaviour) sets use_count to 1 and marks this particular backlight
> > device as used by all available fb devices (since it is not known
> > during probe how much and which fb devices will be assigned).
> >
> > Without this code, the backlight works properly until one tries to
> > blank it manually from sysfs with "echo 1
> > > /sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
> > > were both set to 0, the logic at
> > fb_notifier_callback (@backlight.c) thought that we didn't turn on
> > (unblanked) the backlight device and refuses to disable (blank) it.
> > As a result we see garbage from fb displayed.
>
> COmments/acks are more than welcome :-)
I thought Jingoo already replied to you?
> > Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
> > ---
> > The patch has been tested on i.MX6q with 4.9-rc3
> > SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
> > ---
> > Changes for v2:
> > - Update commit message with proper other commit reference
> >
> > ---
> > drivers/video/backlight/pwm_bl.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/backlight/pwm_bl.c
> > b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -202,7 +202,7 @@ static int pwm_backlight_probe(struct
> > platform_device *pdev) struct pwm_bl_data *pb;
> > int initial_blank = FB_BLANK_UNBLANK;
> > struct pwm_args pargs;
> > - int ret;
> > + int ret, i;
> >
> > if (!data) {
> > ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
> > @@ -348,6 +348,14 @@ static int pwm_backlight_probe(struct
> > platform_device *pdev)
> > bl->props.brightness = data->dft_brightness;
> > bl->props.power = initial_blank;
> > +
> > + if (initial_blank == FB_BLANK_UNBLANK) {
> > + for (i = 0; i < FB_MAX; i++)
> > + bl->fb_bl_on[i] = true;
> > +
> > + bl->use_count = 1;
> > + }
> > +
> > backlight_update_status(bl);
> >
> > platform_set_drvdata(pdev, bl);
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* RE: Shouldn't VFIO virtualize the ATS capability?
From: Ilya Lesokhin @ 2016-11-09 14:49 UTC (permalink / raw)
To: Alex Williamson
Cc: linux-pci@vger.kernel.org, kvm@vger.kernel.org,
bhelgaas@google.com, Adi Menachem
In-Reply-To: <20161106100832.41e173d5@t450s.home>
I would virtualize the "ATS Control Register".
Regarding poor behavior, I couldn't really find what happens when ATS is misconfigured, but I would assume it can cause problems.
The scenarios I'm concerned about are:
1. The guest enables translation caching, while the hypervisor thinks there are disabled -> Hypervisor won't issue invalidations.
2. Smallest Translation Unit misconfiguration. Not sure if it will cause invalid access or only poor caching behavior.
Thanks,
Ilya
> -----Original Message-----
> From: Alex Williamson [mailto:alex.williamson@redhat.com]
> Sent: Sunday, November 06, 2016 7:09 PM
> To: Ilya Lesokhin <ilyal@mellanox.com>
> Cc: linux-pci@vger.kernel.org; kvm@vger.kernel.org; bhelgaas@google.com
> Subject: Re: Shouldn't VFIO virtualize the ATS capability?
>
> On Sun, 6 Nov 2016 11:13:09 +0000
> Ilya Lesokhin <ilyal@mellanox.com> wrote:
>
> > Hi
> > I've noticed that VFIO doesn't virtualize the ATS capability.
> > It seems to me that translation caching and Smallest Translation Unit is
> something you would want to control on the host. Am I wrong?
>
> What about those fields would we virtualize? Why does the host need to be
> an intermediary? Can the user induce poor behavior with direct access to
> them? Thanks,
>
> Alex
^ permalink raw reply
* [PATCH] openssl: fix bashism in c_rehash shell script
From: André Draszik @ 2016-11-09 14:48 UTC (permalink / raw)
To: openembedded-core
From: André Draszik <adraszik@tycoint.com>
This script claims to be a /bin/sh script, but it uses
a bashism:
from checkbashisms:
possible bashism in meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh line 151 (should be 'b = a'):
if [ "x/" == "x$( echo ${FILE} | cut -c1 -)" ]
This causes build issues on systems that don't have
/bin/sh symlinked to bash:
Updating certificates in ${WORKDIR}/rootfs/etc/ssl/certs...
<builddir>/tmp/sysroots/x86_64-linux/usr/bin/c_rehash: 151: [: x/: unexpected operator
...
Fix this by using POSIX shell syntax for the comparison.
Signed-off-by: André Draszik <adraszik@tycoint.com>
Reviewed-by: Sylvain Lemieux <slemieux@tycoint.com>
---
meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh b/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
index 25ea729..6620fdc 100644
--- a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
+++ b/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
@@ -148,7 +148,7 @@ hash_dir()
then
FILE=$( readlink ${FILE} )
# check the symlink is absolute (or dangling in other word)
- if [ "x/" == "x$( echo ${FILE} | cut -c1 -)" ]
+ if [ "x/" = "x$( echo ${FILE} | cut -c1 -)" ]
then
REAL_FILE=${SYSROOT}/${FILE}
fi
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests
From: Paul Durrant @ 2016-11-09 14:48 UTC (permalink / raw)
To: Boris Ostrovsky, xen-devel@lists.xen.org
Cc: Wei Liu, Andrew Cooper, Julien Grall, jbeulich@suse.com,
Ian Jackson, Roger Pau Monne
In-Reply-To: <1478702399-14538-3-git-send-email-boris.ostrovsky@oracle.com>
> -----Original Message-----
> From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]
> Sent: 09 November 2016 14:40
> To: xen-devel@lists.xen.org
> Cc: jbeulich@suse.com; Andrew Cooper <Andrew.Cooper3@citrix.com>;
> Wei Liu <wei.liu2@citrix.com>; Ian Jackson <Ian.Jackson@citrix.com>; Roger
> Pau Monne <roger.pau@citrix.com>; Boris Ostrovsky
> <boris.ostrovsky@oracle.com>; Julien Grall <julien.grall@arm.com>; Paul
> Durrant <Paul.Durrant@citrix.com>
> Subject: [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests
>
> ACPI hotplug-related IO accesses (to GPE0 block) are handled
> by qemu for HVM guests. Since PVH guests don't have qemu these
> accesses will need to be procesed by the hypervisor.
>
> Because ACPI event model expects pm1a block to be present we
> need to have the hypervisor emulate it as well.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
> CC: Julien Grall <julien.grall@arm.com>
> CC: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
> ---
> Changes in v2:
> * Added public macros for ACPI CPU bitmap (at 0xaf00). Note: PRST
> region shrinks from 32 bytes to 16 (when 128 VCPUs are
> supported).
>
>
> tools/libacpi/mk_dsdt.c | 4 +++-
> tools/libacpi/static_tables.c | 28 +++++++++++-----------------
> xen/include/asm-x86/hvm/domain.h | 6 ++++++
> xen/include/public/arch-arm.h | 11 ++++++++---
> xen/include/public/hvm/ioreq.h | 13 +++++++++++++
> 5 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
> index 4ae68bc..2b8234d 100644
> --- a/tools/libacpi/mk_dsdt.c
> +++ b/tools/libacpi/mk_dsdt.c
> @@ -19,6 +19,7 @@
> #include <stdbool.h>
> #if defined(__i386__) || defined(__x86_64__)
> #include <xen/hvm/hvm_info_table.h>
> +#include <xen/hvm/ioreq.h>
> #elif defined(__aarch64__)
> #include <xen/arch-arm.h>
> #endif
> @@ -244,7 +245,8 @@ int main(int argc, char **argv)
> #endif
>
> /* Operation Region 'PRST': bitmask of online CPUs. */
> - stmt("OperationRegion", "PRST, SystemIO, 0xaf00, 32");
> + stmt("OperationRegion", "PRST, SystemIO, 0x%x, %d",
> + ACPI_CPU_MAP, ACPI_CPU_MAP_LEN);
> push_block("Field", "PRST, ByteAcc, NoLock, Preserve");
> indent(); printf("PRS, %u\n", max_cpus);
> pop_block();
> diff --git a/tools/libacpi/static_tables.c b/tools/libacpi/static_tables.c
> index 617bf68..413abcc 100644
> --- a/tools/libacpi/static_tables.c
> +++ b/tools/libacpi/static_tables.c
> @@ -20,6 +20,8 @@
> * Firmware ACPI Control Structure (FACS).
> */
>
> +#define ACPI_REG_BIT_OFFSET 0
> +
> struct acpi_20_facs Facs = {
> .signature = ACPI_2_0_FACS_SIGNATURE,
> .length = sizeof(struct acpi_20_facs),
> @@ -30,14 +32,6 @@ struct acpi_20_facs Facs = {
> /*
> * Fixed ACPI Description Table (FADT).
> */
> -
> -#define ACPI_PM1A_EVT_BLK_BIT_WIDTH 0x20
> -#define ACPI_PM1A_EVT_BLK_BIT_OFFSET 0x00
> -#define ACPI_PM1A_CNT_BLK_BIT_WIDTH 0x10
> -#define ACPI_PM1A_CNT_BLK_BIT_OFFSET 0x00
> -#define ACPI_PM_TMR_BLK_BIT_WIDTH 0x20
> -#define ACPI_PM_TMR_BLK_BIT_OFFSET 0x00
> -
> struct acpi_20_fadt Fadt = {
> .header = {
> .signature = ACPI_2_0_FADT_SIGNATURE,
> @@ -56,9 +50,9 @@ struct acpi_20_fadt Fadt = {
> .pm1a_cnt_blk = ACPI_PM1A_CNT_BLK_ADDRESS_V1,
> .pm_tmr_blk = ACPI_PM_TMR_BLK_ADDRESS_V1,
> .gpe0_blk = ACPI_GPE0_BLK_ADDRESS_V1,
> - .pm1_evt_len = ACPI_PM1A_EVT_BLK_BIT_WIDTH / 8,
> - .pm1_cnt_len = ACPI_PM1A_CNT_BLK_BIT_WIDTH / 8,
> - .pm_tmr_len = ACPI_PM_TMR_BLK_BIT_WIDTH / 8,
> + .pm1_evt_len = ACPI_PM1A_EVT_BLK_LEN,
> + .pm1_cnt_len = ACPI_PM1A_CNT_BLK_LEN,
> + .pm_tmr_len = ACPI_PM_TMR_BLK_LEN,
> .gpe0_blk_len = ACPI_GPE0_BLK_LEN_V1,
>
> .p_lvl2_lat = 0x0fff, /* >100, means we do not support C2 state */
> @@ -79,22 +73,22 @@ struct acpi_20_fadt Fadt = {
>
> .x_pm1a_evt_blk = {
> .address_space_id = ACPI_SYSTEM_IO,
> - .register_bit_width = ACPI_PM1A_EVT_BLK_BIT_WIDTH,
> - .register_bit_offset = ACPI_PM1A_EVT_BLK_BIT_OFFSET,
> + .register_bit_width = ACPI_PM1A_EVT_BLK_LEN * 8,
> + .register_bit_offset = ACPI_REG_BIT_OFFSET,
> .address = ACPI_PM1A_EVT_BLK_ADDRESS_V1,
> },
>
> .x_pm1a_cnt_blk = {
> .address_space_id = ACPI_SYSTEM_IO,
> - .register_bit_width = ACPI_PM1A_CNT_BLK_BIT_WIDTH,
> - .register_bit_offset = ACPI_PM1A_CNT_BLK_BIT_OFFSET,
> + .register_bit_width = ACPI_PM1A_CNT_BLK_LEN * 8,
> + .register_bit_offset = ACPI_REG_BIT_OFFSET,
> .address = ACPI_PM1A_CNT_BLK_ADDRESS_V1,
> },
>
> .x_pm_tmr_blk = {
> .address_space_id = ACPI_SYSTEM_IO,
> - .register_bit_width = ACPI_PM_TMR_BLK_BIT_WIDTH,
> - .register_bit_offset = ACPI_PM_TMR_BLK_BIT_OFFSET,
> + .register_bit_width = ACPI_PM_TMR_BLK_LEN * 8,
> + .register_bit_offset = ACPI_REG_BIT_OFFSET,
> .address = ACPI_PM_TMR_BLK_ADDRESS_V1,
> }
> };
> diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-
> x86/hvm/domain.h
> index f34d784..f492a2b 100644
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -87,6 +87,12 @@ struct hvm_domain {
> } ioreq_server;
> struct hvm_ioreq_server *default_ioreq_server;
>
> + /* PVH guests */
> + struct {
> + uint8_t pm1a[ACPI_PM1A_EVT_BLK_LEN];
> + uint8_t gpe[ACPI_GPE0_BLK_LEN_V1];
> + } acpi_io;
> +
> /* Cached CF8 for guest PCI config cycles */
> uint32_t pci_cf8;
>
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index bd974fb..b793774 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -383,6 +383,9 @@ typedef uint64_t xen_callback_t;
> * should instead use the FDT.
> */
>
> +/* Current supported guest VCPUs */
> +#define GUEST_MAX_VCPUS 128
> +
> /* Physical Address Space */
>
> /*
> @@ -410,6 +413,11 @@ typedef uint64_t xen_callback_t;
> #define GUEST_ACPI_BASE 0x20000000ULL
> #define GUEST_ACPI_SIZE 0x02000000ULL
>
> +/* Location of online VCPU bitmap. */
> +#define ACPI_CPU_MAP 0xaf00
> +#define ACPI_CPU_MAP_LEN ((GUEST_MAX_VCPUS / 8) + \
> + ((GUEST_MAX_VCPUS & 7) ? 1 : 0))
> +
> /*
> * 16MB == 4096 pages reserved for guest to use as a region to map its
> * grant table in.
> @@ -435,9 +443,6 @@ typedef uint64_t xen_callback_t;
> #define GUEST_RAM_BANK_BASES { GUEST_RAM0_BASE,
> GUEST_RAM1_BASE }
> #define GUEST_RAM_BANK_SIZES { GUEST_RAM0_SIZE,
> GUEST_RAM1_SIZE }
>
> -/* Current supported guest VCPUs */
> -#define GUEST_MAX_VCPUS 128
> -
> /* Interrupts */
> #define GUEST_TIMER_VIRT_PPI 27
> #define GUEST_TIMER_PHYS_S_PPI 29
> diff --git a/xen/include/public/hvm/ioreq.h
> b/xen/include/public/hvm/ioreq.h
> index 2e5809b..e3fa704 100644
> --- a/xen/include/public/hvm/ioreq.h
> +++ b/xen/include/public/hvm/ioreq.h
> @@ -24,6 +24,8 @@
> #ifndef _IOREQ_H_
> #define _IOREQ_H_
>
> +#include "hvm_info_table.h" /* HVM_MAX_VCPUS */
> +
> #define IOREQ_READ 1
> #define IOREQ_WRITE 0
>
> @@ -124,6 +126,17 @@ typedef struct buffered_iopage buffered_iopage_t;
> #define ACPI_GPE0_BLK_ADDRESS ACPI_GPE0_BLK_ADDRESS_V0
> #define ACPI_GPE0_BLK_LEN ACPI_GPE0_BLK_LEN_V0
>
> +#define ACPI_PM1A_EVT_BLK_LEN 0x04
> +#define ACPI_PM1A_CNT_BLK_LEN 0x02
> +#define ACPI_PM_TMR_BLK_LEN 0x04
> +
> +/* Location of online VCPU bitmap. */
> +#define ACPI_CPU_MAP 0xaf00
> +#define ACPI_CPU_MAP_LEN ((HVM_MAX_VCPUS / 8) + \
> + ((HVM_MAX_VCPUS & 7) ? 1 : 0))
> +#if ACPI_CPU_MAP + ACPI_CPU_MAP_LEN >=
> ACPI_GPE0_BLK_ADDRESS_V1
> +#error "ACPI_CPU_MAP is too big"
> +#endif
>
> #endif /* _IOREQ_H_ */
>
> --
> 2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests
From: Julien Grall @ 2016-11-09 14:48 UTC (permalink / raw)
To: Boris Ostrovsky, xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, Paul Durrant, jbeulich,
roger.pau
In-Reply-To: <1478702399-14538-3-git-send-email-boris.ostrovsky@oracle.com>
Hi Boris,
On 09/11/16 14:39, Boris Ostrovsky wrote:
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index bd974fb..b793774 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -383,6 +383,9 @@ typedef uint64_t xen_callback_t;
> * should instead use the FDT.
> */
>
> +/* Current supported guest VCPUs */
> +#define GUEST_MAX_VCPUS 128
> +
> /* Physical Address Space */
>
> /*
> @@ -410,6 +413,11 @@ typedef uint64_t xen_callback_t;
> #define GUEST_ACPI_BASE 0x20000000ULL
> #define GUEST_ACPI_SIZE 0x02000000ULL
>
> +/* Location of online VCPU bitmap. */
> +#define ACPI_CPU_MAP 0xaf00
> +#define ACPI_CPU_MAP_LEN ((GUEST_MAX_VCPUS / 8) + \
> + ((GUEST_MAX_VCPUS & 7) ? 1 : 0))
> +
I don't understand this change. PRST is not generated for ARM (see the
return 0 in mk_dsdt a bit before).
In any case, I am expecting CPU hotplug to be handle via PSCI on ARM.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: Help regarding bringing up dom0 for lager board
From: George John @ 2016-11-09 14:47 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel
In-Reply-To: <5e86d582-0a6f-e0cb-b4ed-ca59ffc6a2bc@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1015 bytes --]
Thanks it was really the problem of dts. I just followed the proceedings of
Ferger in Mailing lists who tried to bring up Dom0 in lager, and I got it
booted up. But now the problem is with rootfs. I am checking on that..
Thanks and regards,
George
On Tue, Nov 8, 2016 at 5:20 PM, Julien Grall <julien.grall@arm.com> wrote:
>
>
> On 07/11/2016 16:39, George John wrote:
>
>> Hi,
>>
>
> Hello,
>
> (XEN) Freed 276kB init memory.
>> (XEN) traps.c:2505:d0v0 HSR=0x93820007 pc=0xc001d084 gva=0xe7804060
>> gpa=0x000000e6160060
>>
>
> Looking at the log, DOM0 is trying to access an region that is not mapped
> (0x000000e6160060).
>
> When booting Xen is going through the device tree and mapping to dom0 all
> the regions described. So it seems that this region is not present in the
> device tree.
>
> Which Linux kernel are you using? I would recommend you to try the latest
> as possible and use the device-tree provided in arch/arm/boot/dts/ to see
> if it solves the problem.
>
> Cheers,
>
> --
> Julien Grall
>
[-- Attachment #1.2: Type: text/html, Size: 1713 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
From: Daniel P. Berrange @ 2016-11-09 14:47 UTC (permalink / raw)
To: Andrew Jones
Cc: Laszlo Ersek, Dave Young, qiaonuohan, bhe, anderson, qemu-devel
In-Reply-To: <20161109122051.ztllxmhwsalds2qw@kamzik.brq.redhat.com>
On Wed, Nov 09, 2016 at 01:20:51PM +0100, Andrew Jones wrote:
> On Wed, Nov 09, 2016 at 11:58:19AM +0000, Daniel P. Berrange wrote:
> > On Wed, Nov 09, 2016 at 12:48:09PM +0100, Andrew Jones wrote:
> > > On Wed, Nov 09, 2016 at 11:37:35AM +0000, Daniel P. Berrange wrote:
> > > > On Wed, Nov 09, 2016 at 12:26:17PM +0100, Laszlo Ersek wrote:
> > > > > On 11/09/16 11:40, Andrew Jones wrote:
> > > > > > On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote:
> > > > > >> Hi,
> > > > > >>
> > > > > >> Latest linux kernel enabled kaslr to randomiz phys/virt memory
> > > > > >> addresses, we had some effort to support kexec/kdump so that crash
> > > > > >> utility can still works in case crashed kernel has kaslr enabled.
> > > > > >>
> > > > > >> But according to Dave Anderson virsh dump does not work, quoted messages
> > > > > >> from Dave below:
> > > > > >>
> > > > > >> """
> > > > > >> with virsh dump, there's no way of even knowing that KASLR
> > > > > >> has randomized the kernel __START_KERNEL_map region, because there is no
> > > > > >> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump
> > > > > >> vmcoreinfo data to compare against the vmlinux file symbol value.
> > > > > >> Unless virsh dump can export some basic virtual memory data, which
> > > > > >> they say it can't, I don't see how KASLR can ever be supported.
> > > > > >> """
> > > > > >>
> > > > > >> I assume virsh dump is using qemu guest memory dump facility so it
> > > > > >> should be first addressed in qemu. Thus post this query to qemu devel
> > > > > >> list. If this is not correct please let me know.
> > > > > >>
> > > > > >> Could you qemu dump people make it work? Or we can not support virt dump
> > > > > >> as long as KASLR being enabled. Latest Fedora kernel has enabled it in x86_64.
> > > > > >>
> > > > > >
> > > > > > When the -kernel command line option is used, then it may be possible
> > > > > > to extract some information that could be used to supplement the memory
> > > > > > dump that dump-guest-memory provides. However, that would be a specific
> > > > > > use. In general, QEMU knows nothing about the guest kernel. It doesn't
> > > > > > know where it is in the disk image, and it doesn't even know if it's
> > > > > > Linux.
> > > > > >
> > > > > > Is there anything a guest userspace application could probe from e.g.
> > > > > > /proc that would work? If so, then the guest agent could gain a new
> > > > > > feature providing that.
> > > > >
> > > > > I fully agree. This is exactly what I suggested too, independently, in
> > > > > the downstream thread, before arriving at this upstream thread. Let me
> > > > > quote that email:
> > > > >
> > > > > On 11/09/16 12:09, Laszlo Ersek wrote:
> > > > > > [...] the dump-guest-memory QEMU command supports an option called
> > > > > > "paging". Here's its documentation, from the "qapi-schema.json" source
> > > > > > file:
> > > > > >
> > > > > >> # @paging: if true, do paging to get guest's memory mapping. This allows
> > > > > >> # using gdb to process the core file.
> > > > > >> #
> > > > > >> # IMPORTANT: this option can make QEMU allocate several gigabytes
> > > > > >> # of RAM. This can happen for a large guest, or a
> > > > > >> # malicious guest pretending to be large.
> > > > > >> #
> > > > > >> # Also, paging=true has the following limitations:
> > > > > >> #
> > > > > >> # 1. The guest may be in a catastrophic state or can have corrupted
> > > > > >> # memory, which cannot be trusted
> > > > > >> # 2. The guest can be in real-mode even if paging is enabled. For
> > > > > >> # example, the guest uses ACPI to sleep, and ACPI sleep state
> > > > > >> # goes in real-mode
> > > > > >> # 3. Currently only supported on i386 and x86_64.
> > > > > >> #
> > > > > >
> > > > > > "virsh dump --memory-only" sets paging=false, for obvious reasons.
> > > > > >
> > > > > > [...] the dump-guest-memory command provides a raw snapshot of the
> > > > > > virtual machine's memory (and of the registers of the VCPUs); it is
> > > > > > not enlightened about the guest.
> > > > > >
> > > > > > If the additional information you are looking for can be retrieved
> > > > > > within the running Linux guest, using an appropriately privieleged
> > > > > > userspace process, then I would recommend considering an extension to
> > > > > > the qemu guest agent. The management layer (libvirt, [...]) could
> > > > > > first invoke the guest agent (a process with root privileges running
> > > > > > in the guest) from the host side, through virtio-serial. The new guest
> > > > > > agent command would return the information necessary to deal with
> > > > > > KASLR. Then the management layer would initiate the dump like always.
> > > > > > Finally, the extra information would be combined with (or placed
> > > > > > beside) the dump file in some way.
> > > > > >
> > > > > > So, this proposal would affect the guest agent and the management
> > > > > > layer (= libvirt).
> > > > >
> > > > > Given that we already dislike "paging=true", enlightening
> > > > > dump-guest-memory with even more guest-specific insight is the wrong
> > > > > approach, IMO. That kind of knowledge belongs to the guest agent.
> > > >
> > > > If you're trying to debug a hung/panicked guest, then using a guest
> > > > agent to fetch info is a complete non-starter as it'll be dead.
> > >
> > > So don't wait. Management software can make this query immediately
> > > after the guest agent goes live. The information needed won't change.
> >
> > That doesn't help with trying to diagnose a crash during boot up, since
> > the guest agent isn't running till fairly late. I'm also concerned that
> > the QEMU guest agent is likely to be far from widely deployed in guests,
> > so reliance on the guest agent will mean the dump facility is no longer
> > reliably available.
> >
>
> It'd still be reliably available and useable during early boot, just like
> it is now, for kernels that don't use KASLR. This proposal is only
> attempting to *also* address KASLR kernels, for which there is currently
> no support whatsoever. Call it a best-effort.
>
> Of course we can get support for [probably] early boot and
> guest-agent-less guests using KASLR too if we introduce a paravirt
> solution, requiring guest kernel and KVM changes. Is it worth it?
There's a standard for persistent storage that is intended to allow
the kernel to dump out data at time of crash:
https://lwn.net/Articles/434821/
and there's some recent patches to provide a QEMU backend. Could we
leverage that facility to get the data we need from the guest kernel ?
Instead of only using pstore at time of crash, the kernel could see
that its running on KVM, and write out the paging data to pstore. So
when QEMU later generates a core dump, it can grab the corresponding
data from pstore backend ?
Still requires an extra device, to be configured, but at lesat we
would not have to invent yet another paravirt device ourselves, just
use the existing framework.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
^ permalink raw reply
* Re: [PATCH v1 03/19] split-index: add {add,remove}_split_index() functions
From: Christian Couder @ 2016-11-09 14:47 UTC (permalink / raw)
To: Duy Nguyen
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <CACsJy8AisF2ZVs7JdnVFp5wdskkbVQQQ=DBq5UzE1MOsCfBMtQ@mail.gmail.com>
On Wed, Nov 9, 2016 at 10:24 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Mon, Nov 7, 2016 at 5:08 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Sun, Oct 30, 2016 at 5:06 AM, Christian Couder
>> <christian.couder@gmail.com> wrote:
>>> On Tue, Oct 25, 2016 at 11:58 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>>>> On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
>>>> <christian.couder@gmail.com> wrote:
>>>>> +void remove_split_index(struct index_state *istate)
>>>>> +{
>>>>> + if (istate->split_index) {
>>>>> + /*
>>>>> + * can't discard_split_index(&the_index); because that
>>>>> + * will destroy split_index->base->cache[], which may
>>>>> + * be shared with the_index.cache[]. So yeah we're
>>>>> + * leaking a bit here.
>>>>
>>>> In the context of update-index, this is a one-time thing and leaking
>>>> is tolerable. But because it becomes a library function now, this leak
>>>> can become more serious, I think.
>>>>
>>>> The only other (indirect) caller is read_index_from() so probably not
>>>> bad most of the time (we read at the beginning of a command only).
>>>> sequencer.c may discard and re-read the index many times though,
>>>> leaking could be visible there.
>>>
>>> So is it enough to check if split_index->base->cache[] is shared with
>>> the_index.cache[] and then decide if discard_split_index(&the_index)
>>> should be called?
>>
>> It's likely shared though. We could un-share cache[] by duplicating
>> index entries in the_index.cache[] if they point back to
>> split_index->base
>
> I have a patch for this. So don't have to do anything else in this
> area. I'll probably just pile my patch on top of your series, or post
> it once the series graduates to master.
Great, thanks!
^ permalink raw reply
* Re: [watchdog] watchdog: mei_wdt: request stop on reboot to prevent false positive event
From: Guenter Roeck @ 2016-11-09 14:47 UTC (permalink / raw)
To: Tomas Winkler, Wim Van Sebroeck
Cc: linux-watchdog, linux-kernel, Alexander Usyskin, stable
In-Reply-To: <1478620552-30409-1-git-send-email-tomas.winkler@intel.com>
On 11/08/2016 07:55 AM, Tomas Winkler wrote:
> From: Alexander Usyskin <alexander.usyskin@intel.com>
>
> Systemd on reboot enables shutdown watchdog that leaves the watchdog
> device open to ensure that even if power down process get stuck the
> platform reboots nonetheless.
> The iamt_wdt is an alarm-only watchdog and can't reboot system, but the
> FW will generate an alarm event reboot was completed in time, as the
> watchdog is not automatically disabled during power cycle.
> So we should request stop watchdog on reboot to eliminate wrong alarm
> from the FW.
>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/watchdog/mei_wdt.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
> index e0af52265511..40953fe4db86 100644
> --- a/drivers/watchdog/mei_wdt.c
> +++ b/drivers/watchdog/mei_wdt.c
> @@ -389,6 +389,8 @@ static int mei_wdt_register(struct mei_wdt *wdt)
> wdt->wdd.max_timeout = MEI_WDT_MAX_TIMEOUT;
>
> watchdog_set_drvdata(&wdt->wdd, wdt);
> + watchdog_stop_on_reboot(&wdt->wdd);
> +
> ret = watchdog_register_device(&wdt->wdd);
> if (ret) {
> dev_err(dev, "unable to register watchdog device = %d.\n", ret);
>
^ permalink raw reply
* [BACKPORT PATCH 3.10..3.16] KVM: MIPS: Drop other CPU ASIDs on guest MMU changes
From: James Hogan @ 2016-11-09 14:46 UTC (permalink / raw)
To: Jiri Slaby, stable
Cc: Paolo Bonzini, Radim Krčmář, Ralf Baechle,
linux-mips, kvm, James Hogan
commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream.
When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate
TLB entries on the local CPU. This doesn't work correctly on an SMP host
when the guest is migrated to a different physical CPU, as it could pick
up stale TLB mappings from the last time the vCPU ran on that physical
CPU.
Therefore invalidate both user and kernel host ASIDs on other CPUs,
which will cause new ASIDs to be generated when it next runs on those
CPUs.
We're careful only to do this if the TLB entry was already valid, and
only for the kernel ASID where the virtual address it mapped is outside
of the guest user address range.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc: <stable@vger.kernel.org> # 3.10.x-
Cc: Jiri Slaby <jslaby@suse.cz>
[james.hogan@imgtec.com: Backport to 3.10..3.16]
Signed-off-by: James Hogan <james.hogan@imgtec.com>
---
Unfortunately the original commit went in to v3.12.65 as commit
168e5ebbd63e, without fixing up the references to tlb_lo[0/1] to
tlb_lo0/1 which broke the MIPS KVM build, and I didn't twig that I
already had a correct backport outstanding (sorry!). That commit should
be reverted before applying this backport to 3.12.
---
arch/mips/kvm/kvm_mips_emul.c | 61 +++++++++++++++++++++++++++++++++++++------
1 file changed, 53 insertions(+), 8 deletions(-)
diff --git a/arch/mips/kvm/kvm_mips_emul.c b/arch/mips/kvm/kvm_mips_emul.c
index 1983678883c9..d0eb34279955 100644
--- a/arch/mips/kvm/kvm_mips_emul.c
+++ b/arch/mips/kvm/kvm_mips_emul.c
@@ -817,6 +817,47 @@ enum emulation_result kvm_mips_emul_tlbr(struct kvm_vcpu *vcpu)
return er;
}
+/**
+ * kvm_mips_invalidate_guest_tlb() - Indicates a change in guest MMU map.
+ * @vcpu: VCPU with changed mappings.
+ * @tlb: TLB entry being removed.
+ *
+ * This is called to indicate a single change in guest MMU mappings, so that we
+ * can arrange TLB flushes on this and other CPUs.
+ */
+static void kvm_mips_invalidate_guest_tlb(struct kvm_vcpu *vcpu,
+ struct kvm_mips_tlb *tlb)
+{
+ int cpu, i;
+ bool user;
+
+ /* No need to flush for entries which are already invalid */
+ if (!((tlb->tlb_lo0 | tlb->tlb_lo1) & MIPS3_PG_V))
+ return;
+ /* User address space doesn't need flushing for KSeg2/3 changes */
+ user = tlb->tlb_hi < KVM_GUEST_KSEG0;
+
+ preempt_disable();
+
+ /*
+ * Probe the shadow host TLB for the entry being overwritten, if one
+ * matches, invalidate it
+ */
+ kvm_mips_host_tlb_inv(vcpu, tlb->tlb_hi);
+
+ /* Invalidate the whole ASID on other CPUs */
+ cpu = smp_processor_id();
+ for_each_possible_cpu(i) {
+ if (i == cpu)
+ continue;
+ if (user)
+ vcpu->arch.guest_user_asid[i] = 0;
+ vcpu->arch.guest_kernel_asid[i] = 0;
+ }
+
+ preempt_enable();
+}
+
/* Write Guest TLB Entry @ Index */
enum emulation_result kvm_mips_emul_tlbwi(struct kvm_vcpu *vcpu)
{
@@ -838,10 +879,8 @@ enum emulation_result kvm_mips_emul_tlbwi(struct kvm_vcpu *vcpu)
}
tlb = &vcpu->arch.guest_tlb[index];
-#if 1
- /* Probe the shadow host TLB for the entry being overwritten, if one matches, invalidate it */
- kvm_mips_host_tlb_inv(vcpu, tlb->tlb_hi);
-#endif
+
+ kvm_mips_invalidate_guest_tlb(vcpu, tlb);
tlb->tlb_mask = kvm_read_c0_guest_pagemask(cop0);
tlb->tlb_hi = kvm_read_c0_guest_entryhi(cop0);
@@ -880,10 +919,7 @@ enum emulation_result kvm_mips_emul_tlbwr(struct kvm_vcpu *vcpu)
tlb = &vcpu->arch.guest_tlb[index];
-#if 1
- /* Probe the shadow host TLB for the entry being overwritten, if one matches, invalidate it */
- kvm_mips_host_tlb_inv(vcpu, tlb->tlb_hi);
-#endif
+ kvm_mips_invalidate_guest_tlb(vcpu, tlb);
tlb->tlb_mask = kvm_read_c0_guest_pagemask(cop0);
tlb->tlb_hi = kvm_read_c0_guest_entryhi(cop0);
@@ -926,6 +962,7 @@ kvm_mips_emulate_CP0(uint32_t inst, uint32_t *opc, uint32_t cause,
int32_t rt, rd, copz, sel, co_bit, op;
uint32_t pc = vcpu->arch.pc;
unsigned long curr_pc;
+ int cpu, i;
/*
* Update PC and hold onto current PC in case there is
@@ -1037,8 +1074,16 @@ kvm_mips_emulate_CP0(uint32_t inst, uint32_t *opc, uint32_t cause,
ASID_MASK,
vcpu->arch.gprs[rt] & ASID_MASK);
+ preempt_disable();
/* Blow away the shadow host TLBs */
kvm_mips_flush_host_tlb(1);
+ cpu = smp_processor_id();
+ for_each_possible_cpu(i)
+ if (i != cpu) {
+ vcpu->arch.guest_user_asid[i] = 0;
+ vcpu->arch.guest_kernel_asid[i] = 0;
+ }
+ preempt_enable();
}
kvm_write_c0_guest_entryhi(cop0,
vcpu->arch.gprs[rt]);
--
2.10.1
^ permalink raw reply related
* [BACKPORT PATCH 3.10..3.16] KVM: MIPS: Drop other CPU ASIDs on guest MMU changes
From: James Hogan @ 2016-11-09 14:46 UTC (permalink / raw)
To: Jiri Slaby, stable
Cc: Paolo Bonzini, Radim Krčmář, Ralf Baechle,
linux-mips, kvm, James Hogan
commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream.
When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate
TLB entries on the local CPU. This doesn't work correctly on an SMP host
when the guest is migrated to a different physical CPU, as it could pick
up stale TLB mappings from the last time the vCPU ran on that physical
CPU.
Therefore invalidate both user and kernel host ASIDs on other CPUs,
which will cause new ASIDs to be generated when it next runs on those
CPUs.
We're careful only to do this if the TLB entry was already valid, and
only for the kernel ASID where the virtual address it mapped is outside
of the guest user address range.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc: <stable@vger.kernel.org> # 3.10.x-
Cc: Jiri Slaby <jslaby@suse.cz>
[james.hogan@imgtec.com: Backport to 3.10..3.16]
Signed-off-by: James Hogan <james.hogan@imgtec.com>
---
Unfortunately the original commit went in to v3.12.65 as commit
168e5ebbd63e, without fixing up the references to tlb_lo[0/1] to
tlb_lo0/1 which broke the MIPS KVM build, and I didn't twig that I
already had a correct backport outstanding (sorry!). That commit should
be reverted before applying this backport to 3.12.
---
arch/mips/kvm/kvm_mips_emul.c | 61 +++++++++++++++++++++++++++++++++++++------
1 file changed, 53 insertions(+), 8 deletions(-)
diff --git a/arch/mips/kvm/kvm_mips_emul.c b/arch/mips/kvm/kvm_mips_emul.c
index 1983678883c9..d0eb34279955 100644
--- a/arch/mips/kvm/kvm_mips_emul.c
+++ b/arch/mips/kvm/kvm_mips_emul.c
@@ -817,6 +817,47 @@ enum emulation_result kvm_mips_emul_tlbr(struct kvm_vcpu *vcpu)
return er;
}
+/**
+ * kvm_mips_invalidate_guest_tlb() - Indicates a change in guest MMU map.
+ * @vcpu: VCPU with changed mappings.
+ * @tlb: TLB entry being removed.
+ *
+ * This is called to indicate a single change in guest MMU mappings, so that we
+ * can arrange TLB flushes on this and other CPUs.
+ */
+static void kvm_mips_invalidate_guest_tlb(struct kvm_vcpu *vcpu,
+ struct kvm_mips_tlb *tlb)
+{
+ int cpu, i;
+ bool user;
+
+ /* No need to flush for entries which are already invalid */
+ if (!((tlb->tlb_lo0 | tlb->tlb_lo1) & MIPS3_PG_V))
+ return;
+ /* User address space doesn't need flushing for KSeg2/3 changes */
+ user = tlb->tlb_hi < KVM_GUEST_KSEG0;
+
+ preempt_disable();
+
+ /*
+ * Probe the shadow host TLB for the entry being overwritten, if one
+ * matches, invalidate it
+ */
+ kvm_mips_host_tlb_inv(vcpu, tlb->tlb_hi);
+
+ /* Invalidate the whole ASID on other CPUs */
+ cpu = smp_processor_id();
+ for_each_possible_cpu(i) {
+ if (i == cpu)
+ continue;
+ if (user)
+ vcpu->arch.guest_user_asid[i] = 0;
+ vcpu->arch.guest_kernel_asid[i] = 0;
+ }
+
+ preempt_enable();
+}
+
/* Write Guest TLB Entry @ Index */
enum emulation_result kvm_mips_emul_tlbwi(struct kvm_vcpu *vcpu)
{
@@ -838,10 +879,8 @@ enum emulation_result kvm_mips_emul_tlbwi(struct kvm_vcpu *vcpu)
}
tlb = &vcpu->arch.guest_tlb[index];
-#if 1
- /* Probe the shadow host TLB for the entry being overwritten, if one matches, invalidate it */
- kvm_mips_host_tlb_inv(vcpu, tlb->tlb_hi);
-#endif
+
+ kvm_mips_invalidate_guest_tlb(vcpu, tlb);
tlb->tlb_mask = kvm_read_c0_guest_pagemask(cop0);
tlb->tlb_hi = kvm_read_c0_guest_entryhi(cop0);
@@ -880,10 +919,7 @@ enum emulation_result kvm_mips_emul_tlbwr(struct kvm_vcpu *vcpu)
tlb = &vcpu->arch.guest_tlb[index];
-#if 1
- /* Probe the shadow host TLB for the entry being overwritten, if one matches, invalidate it */
- kvm_mips_host_tlb_inv(vcpu, tlb->tlb_hi);
-#endif
+ kvm_mips_invalidate_guest_tlb(vcpu, tlb);
tlb->tlb_mask = kvm_read_c0_guest_pagemask(cop0);
tlb->tlb_hi = kvm_read_c0_guest_entryhi(cop0);
@@ -926,6 +962,7 @@ kvm_mips_emulate_CP0(uint32_t inst, uint32_t *opc, uint32_t cause,
int32_t rt, rd, copz, sel, co_bit, op;
uint32_t pc = vcpu->arch.pc;
unsigned long curr_pc;
+ int cpu, i;
/*
* Update PC and hold onto current PC in case there is
@@ -1037,8 +1074,16 @@ kvm_mips_emulate_CP0(uint32_t inst, uint32_t *opc, uint32_t cause,
ASID_MASK,
vcpu->arch.gprs[rt] & ASID_MASK);
+ preempt_disable();
/* Blow away the shadow host TLBs */
kvm_mips_flush_host_tlb(1);
+ cpu = smp_processor_id();
+ for_each_possible_cpu(i)
+ if (i != cpu) {
+ vcpu->arch.guest_user_asid[i] = 0;
+ vcpu->arch.guest_kernel_asid[i] = 0;
+ }
+ preempt_enable();
}
kvm_write_c0_guest_entryhi(cop0,
vcpu->arch.gprs[rt]);
--
2.10.1
^ permalink raw reply related
* Re: [PATCH 3/4] perf hist browser: Fix column indentation on --hierarchy
From: Arnaldo Carvalho de Melo @ 2016-11-09 14:45 UTC (permalink / raw)
To: Namhyung Kim
Cc: Ingo Molnar, Peter Zijlstra, Jiri Olsa, LKML, Markus Trippelsdorf
In-Reply-To: <20161108130833.9263-4-namhyung@kernel.org>
Em Tue, Nov 08, 2016 at 10:08:32PM +0900, Namhyung Kim escreveu:
> When horizontall scrolling is used in hierarchy mode, the the right most
> column has unnecessary indentation. Actually it's needed only if some
> of left (overhead) columns were shown.
I see, here is the fix, thanks, testing it now...
- Arnaldo
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> ---
> tools/perf/ui/browsers/hists.c | 19 +++++++++++++------
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
> index 7722ad311318..15b29a79a69b 100644
> --- a/tools/perf/ui/browsers/hists.c
> +++ b/tools/perf/ui/browsers/hists.c
> @@ -1361,8 +1361,10 @@ static int hist_browser__show_hierarchy_entry(struct hist_browser *browser,
> width -= hpp.buf - s;
> }
>
> - ui_browser__write_nstring(&browser->b, "", hierarchy_indent);
> - width -= hierarchy_indent;
> + if (!first) {
> + ui_browser__write_nstring(&browser->b, "", hierarchy_indent);
> + width -= hierarchy_indent;
> + }
>
> if (column >= browser->b.horiz_scroll) {
> char s[2048];
> @@ -1565,6 +1567,7 @@ static int hists_browser__scnprintf_hierarchy_headers(struct hist_browser *brows
> if (advance_hpp_check(&dummy_hpp, ret))
> return ret;
>
> + first_node = true;
> /* the first hpp_list_node is for overhead columns */
> fmt_node = list_first_entry(&hists->hpp_formats,
> struct perf_hpp_list_node, list);
> @@ -1579,12 +1582,16 @@ static int hists_browser__scnprintf_hierarchy_headers(struct hist_browser *brows
> ret = scnprintf(dummy_hpp.buf, dummy_hpp.size, " ");
> if (advance_hpp_check(&dummy_hpp, ret))
> break;
> +
> + first_node = false;
> }
>
> - ret = scnprintf(dummy_hpp.buf, dummy_hpp.size, "%*s",
> - indent * HIERARCHY_INDENT, "");
> - if (advance_hpp_check(&dummy_hpp, ret))
> - return ret;
> + if (!first_node) {
> + ret = scnprintf(dummy_hpp.buf, dummy_hpp.size, "%*s",
> + indent * HIERARCHY_INDENT, "");
> + if (advance_hpp_check(&dummy_hpp, ret))
> + return ret;
> + }
>
> first_node = true;
> list_for_each_entry_continue(fmt_node, &hists->hpp_formats, list) {
> --
> 2.10.1
^ permalink raw reply
* [BACKPORT PATCH 3.17..4.4] KVM: MIPS: Drop other CPU ASIDs on guest MMU changes
From: James Hogan @ 2016-11-09 14:45 UTC (permalink / raw)
To: stable
Cc: Paolo Bonzini, Radim Krčmář, Ralf Baechle,
linux-mips, kvm, James Hogan
commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream.
When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate
TLB entries on the local CPU. This doesn't work correctly on an SMP host
when the guest is migrated to a different physical CPU, as it could pick
up stale TLB mappings from the last time the vCPU ran on that physical
CPU.
Therefore invalidate both user and kernel host ASIDs on other CPUs,
which will cause new ASIDs to be generated when it next runs on those
CPUs.
We're careful only to do this if the TLB entry was already valid, and
only for the kernel ASID where the virtual address it mapped is outside
of the guest user address range.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc: <stable@vger.kernel.org> # 3.17.x-
[james.hogan@imgtec.com: Backport to 3.17..4.4]
Signed-off-by: James Hogan <james.hogan@imgtec.com>
---
Unfortunately the original commit went in to v4.4.25 as commit
d450527ad04a, without fixing up the references to tlb_lo[0/1] to
tlb_lo0/1 which broke the MIPS KVM build, and I didn't twig that I
already had a correct backport outstanding (sorry!). That commit should
be reverted before applying this backport to 4.4.
---
arch/mips/kvm/emulate.c | 63 +++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 53 insertions(+), 10 deletions(-)
diff --git a/arch/mips/kvm/emulate.c b/arch/mips/kvm/emulate.c
index d6476d11212e..03344f5ec499 100644
--- a/arch/mips/kvm/emulate.c
+++ b/arch/mips/kvm/emulate.c
@@ -807,6 +807,47 @@ enum emulation_result kvm_mips_emul_tlbr(struct kvm_vcpu *vcpu)
return EMULATE_FAIL;
}
+/**
+ * kvm_mips_invalidate_guest_tlb() - Indicates a change in guest MMU map.
+ * @vcpu: VCPU with changed mappings.
+ * @tlb: TLB entry being removed.
+ *
+ * This is called to indicate a single change in guest MMU mappings, so that we
+ * can arrange TLB flushes on this and other CPUs.
+ */
+static void kvm_mips_invalidate_guest_tlb(struct kvm_vcpu *vcpu,
+ struct kvm_mips_tlb *tlb)
+{
+ int cpu, i;
+ bool user;
+
+ /* No need to flush for entries which are already invalid */
+ if (!((tlb->tlb_lo0 | tlb->tlb_lo1) & MIPS3_PG_V))
+ return;
+ /* User address space doesn't need flushing for KSeg2/3 changes */
+ user = tlb->tlb_hi < KVM_GUEST_KSEG0;
+
+ preempt_disable();
+
+ /*
+ * Probe the shadow host TLB for the entry being overwritten, if one
+ * matches, invalidate it
+ */
+ kvm_mips_host_tlb_inv(vcpu, tlb->tlb_hi);
+
+ /* Invalidate the whole ASID on other CPUs */
+ cpu = smp_processor_id();
+ for_each_possible_cpu(i) {
+ if (i == cpu)
+ continue;
+ if (user)
+ vcpu->arch.guest_user_asid[i] = 0;
+ vcpu->arch.guest_kernel_asid[i] = 0;
+ }
+
+ preempt_enable();
+}
+
/* Write Guest TLB Entry @ Index */
enum emulation_result kvm_mips_emul_tlbwi(struct kvm_vcpu *vcpu)
{
@@ -826,11 +867,8 @@ enum emulation_result kvm_mips_emul_tlbwi(struct kvm_vcpu *vcpu)
}
tlb = &vcpu->arch.guest_tlb[index];
- /*
- * Probe the shadow host TLB for the entry being overwritten, if one
- * matches, invalidate it
- */
- kvm_mips_host_tlb_inv(vcpu, tlb->tlb_hi);
+
+ kvm_mips_invalidate_guest_tlb(vcpu, tlb);
tlb->tlb_mask = kvm_read_c0_guest_pagemask(cop0);
tlb->tlb_hi = kvm_read_c0_guest_entryhi(cop0);
@@ -859,11 +897,7 @@ enum emulation_result kvm_mips_emul_tlbwr(struct kvm_vcpu *vcpu)
tlb = &vcpu->arch.guest_tlb[index];
- /*
- * Probe the shadow host TLB for the entry being overwritten, if one
- * matches, invalidate it
- */
- kvm_mips_host_tlb_inv(vcpu, tlb->tlb_hi);
+ kvm_mips_invalidate_guest_tlb(vcpu, tlb);
tlb->tlb_mask = kvm_read_c0_guest_pagemask(cop0);
tlb->tlb_hi = kvm_read_c0_guest_entryhi(cop0);
@@ -982,6 +1016,7 @@ enum emulation_result kvm_mips_emulate_CP0(uint32_t inst, uint32_t *opc,
int32_t rt, rd, copz, sel, co_bit, op;
uint32_t pc = vcpu->arch.pc;
unsigned long curr_pc;
+ int cpu, i;
/*
* Update PC and hold onto current PC in case there is
@@ -1089,8 +1124,16 @@ enum emulation_result kvm_mips_emulate_CP0(uint32_t inst, uint32_t *opc,
vcpu->arch.gprs[rt]
& ASID_MASK);
+ preempt_disable();
/* Blow away the shadow host TLBs */
kvm_mips_flush_host_tlb(1);
+ cpu = smp_processor_id();
+ for_each_possible_cpu(i)
+ if (i != cpu) {
+ vcpu->arch.guest_user_asid[i] = 0;
+ vcpu->arch.guest_kernel_asid[i] = 0;
+ }
+ preempt_enable();
}
kvm_write_c0_guest_entryhi(cop0,
vcpu->arch.gprs[rt]);
--
2.10.1
^ permalink raw reply related
* [BACKPORT PATCH 3.17..4.4] KVM: MIPS: Drop other CPU ASIDs on guest MMU changes
From: James Hogan @ 2016-11-09 14:45 UTC (permalink / raw)
To: stable
Cc: Paolo Bonzini, Radim Krčmář, Ralf Baechle,
linux-mips, kvm, James Hogan
commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream.
When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate
TLB entries on the local CPU. This doesn't work correctly on an SMP host
when the guest is migrated to a different physical CPU, as it could pick
up stale TLB mappings from the last time the vCPU ran on that physical
CPU.
Therefore invalidate both user and kernel host ASIDs on other CPUs,
which will cause new ASIDs to be generated when it next runs on those
CPUs.
We're careful only to do this if the TLB entry was already valid, and
only for the kernel ASID where the virtual address it mapped is outside
of the guest user address range.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc: <stable@vger.kernel.org> # 3.17.x-
[james.hogan@imgtec.com: Backport to 3.17..4.4]
Signed-off-by: James Hogan <james.hogan@imgtec.com>
---
Unfortunately the original commit went in to v4.4.25 as commit
d450527ad04a, without fixing up the references to tlb_lo[0/1] to
tlb_lo0/1 which broke the MIPS KVM build, and I didn't twig that I
already had a correct backport outstanding (sorry!). That commit should
be reverted before applying this backport to 4.4.
---
arch/mips/kvm/emulate.c | 63 +++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 53 insertions(+), 10 deletions(-)
diff --git a/arch/mips/kvm/emulate.c b/arch/mips/kvm/emulate.c
index d6476d11212e..03344f5ec499 100644
--- a/arch/mips/kvm/emulate.c
+++ b/arch/mips/kvm/emulate.c
@@ -807,6 +807,47 @@ enum emulation_result kvm_mips_emul_tlbr(struct kvm_vcpu *vcpu)
return EMULATE_FAIL;
}
+/**
+ * kvm_mips_invalidate_guest_tlb() - Indicates a change in guest MMU map.
+ * @vcpu: VCPU with changed mappings.
+ * @tlb: TLB entry being removed.
+ *
+ * This is called to indicate a single change in guest MMU mappings, so that we
+ * can arrange TLB flushes on this and other CPUs.
+ */
+static void kvm_mips_invalidate_guest_tlb(struct kvm_vcpu *vcpu,
+ struct kvm_mips_tlb *tlb)
+{
+ int cpu, i;
+ bool user;
+
+ /* No need to flush for entries which are already invalid */
+ if (!((tlb->tlb_lo0 | tlb->tlb_lo1) & MIPS3_PG_V))
+ return;
+ /* User address space doesn't need flushing for KSeg2/3 changes */
+ user = tlb->tlb_hi < KVM_GUEST_KSEG0;
+
+ preempt_disable();
+
+ /*
+ * Probe the shadow host TLB for the entry being overwritten, if one
+ * matches, invalidate it
+ */
+ kvm_mips_host_tlb_inv(vcpu, tlb->tlb_hi);
+
+ /* Invalidate the whole ASID on other CPUs */
+ cpu = smp_processor_id();
+ for_each_possible_cpu(i) {
+ if (i == cpu)
+ continue;
+ if (user)
+ vcpu->arch.guest_user_asid[i] = 0;
+ vcpu->arch.guest_kernel_asid[i] = 0;
+ }
+
+ preempt_enable();
+}
+
/* Write Guest TLB Entry @ Index */
enum emulation_result kvm_mips_emul_tlbwi(struct kvm_vcpu *vcpu)
{
@@ -826,11 +867,8 @@ enum emulation_result kvm_mips_emul_tlbwi(struct kvm_vcpu *vcpu)
}
tlb = &vcpu->arch.guest_tlb[index];
- /*
- * Probe the shadow host TLB for the entry being overwritten, if one
- * matches, invalidate it
- */
- kvm_mips_host_tlb_inv(vcpu, tlb->tlb_hi);
+
+ kvm_mips_invalidate_guest_tlb(vcpu, tlb);
tlb->tlb_mask = kvm_read_c0_guest_pagemask(cop0);
tlb->tlb_hi = kvm_read_c0_guest_entryhi(cop0);
@@ -859,11 +897,7 @@ enum emulation_result kvm_mips_emul_tlbwr(struct kvm_vcpu *vcpu)
tlb = &vcpu->arch.guest_tlb[index];
- /*
- * Probe the shadow host TLB for the entry being overwritten, if one
- * matches, invalidate it
- */
- kvm_mips_host_tlb_inv(vcpu, tlb->tlb_hi);
+ kvm_mips_invalidate_guest_tlb(vcpu, tlb);
tlb->tlb_mask = kvm_read_c0_guest_pagemask(cop0);
tlb->tlb_hi = kvm_read_c0_guest_entryhi(cop0);
@@ -982,6 +1016,7 @@ enum emulation_result kvm_mips_emulate_CP0(uint32_t inst, uint32_t *opc,
int32_t rt, rd, copz, sel, co_bit, op;
uint32_t pc = vcpu->arch.pc;
unsigned long curr_pc;
+ int cpu, i;
/*
* Update PC and hold onto current PC in case there is
@@ -1089,8 +1124,16 @@ enum emulation_result kvm_mips_emulate_CP0(uint32_t inst, uint32_t *opc,
vcpu->arch.gprs[rt]
& ASID_MASK);
+ preempt_disable();
/* Blow away the shadow host TLBs */
kvm_mips_flush_host_tlb(1);
+ cpu = smp_processor_id();
+ for_each_possible_cpu(i)
+ if (i != cpu) {
+ vcpu->arch.guest_user_asid[i] = 0;
+ vcpu->arch.guest_kernel_asid[i] = 0;
+ }
+ preempt_enable();
}
kvm_write_c0_guest_entryhi(cop0,
vcpu->arch.gprs[rt]);
--
2.10.1
^ permalink raw reply related
* Re: [PATCH 3/6] net: mdio-mux: Add MDIO mux driver for NSP SoC
From: Andrew Lunn @ 2016-11-09 14:45 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy
Cc: Rob Herring, Mark Rutland, Russell King, Ray Jui, Scott Branden,
Jon Mason, Florian Fainelli, Kishon Vijay Abraham I,
bcm-kernel-feedback-list, netdev, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1478683994-12008-4-git-send-email-yendapally.reddy@broadcom.com>
> +#define NSP_MDIO_EXT_BUS_START_ADDR 16
> +#define NSP_MDIO_EXT_SELECT_BIT BIT(9)
> +
> +static int mdio_mux_nsp_switch_fn(int current_child, int desired_child,
> + void *priv)
> +{
> + struct nsp_mdiomux_desc *md = priv;
> + u32 data, bus_id;
> +
> + /* select internal or external bus */
> + data = readl(md->mgmt_ctrl);
> + if (desired_child == NSP_MDIO_EXT_BUS_START_ADDR)
> + data |= NSP_MDIO_EXT_SELECT_BIT;
> + else
> + data &= ~NSP_MDIO_EXT_SELECT_BIT;
> + writel(data, md->mgmt_ctrl);
> +
> + /* select bus number */
> + if (md->bus_ctrl) {
> + bus_id = desired_child & (NSP_MDIO_EXT_BUS_START_ADDR - 1);
> + writel(bus_id, md->bus_ctrl);
> + }
> +
> + return 0;
So address 16 is external. What happens which you try to access
address 16 internally? Does the chip raise an abort? Reads just give
0xffff?
I'm wondering if it would be better to implement this as two nested
muxes. One mux doing internal/external, and the other doing the bus.
If you do that, you can use the existing mdio-mux-mmioreg.c and don't
need any new code at all.
Andrew
^ permalink raw reply
* [PATCH 3/6] net: mdio-mux: Add MDIO mux driver for NSP SoC
From: Andrew Lunn @ 2016-11-09 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478683994-12008-4-git-send-email-yendapally.reddy@broadcom.com>
> +#define NSP_MDIO_EXT_BUS_START_ADDR 16
> +#define NSP_MDIO_EXT_SELECT_BIT BIT(9)
> +
> +static int mdio_mux_nsp_switch_fn(int current_child, int desired_child,
> + void *priv)
> +{
> + struct nsp_mdiomux_desc *md = priv;
> + u32 data, bus_id;
> +
> + /* select internal or external bus */
> + data = readl(md->mgmt_ctrl);
> + if (desired_child == NSP_MDIO_EXT_BUS_START_ADDR)
> + data |= NSP_MDIO_EXT_SELECT_BIT;
> + else
> + data &= ~NSP_MDIO_EXT_SELECT_BIT;
> + writel(data, md->mgmt_ctrl);
> +
> + /* select bus number */
> + if (md->bus_ctrl) {
> + bus_id = desired_child & (NSP_MDIO_EXT_BUS_START_ADDR - 1);
> + writel(bus_id, md->bus_ctrl);
> + }
> +
> + return 0;
So address 16 is external. What happens which you try to access
address 16 internally? Does the chip raise an abort? Reads just give
0xffff?
I'm wondering if it would be better to implement this as two nested
muxes. One mux doing internal/external, and the other doing the bus.
If you do that, you can use the existing mdio-mux-mmioreg.c and don't
need any new code at all.
Andrew
^ permalink raw reply
* Re: [PATCH] drm/i915: Trim the object sg table
From: Chris Wilson @ 2016-11-09 14:44 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: Intel-gfx
In-Reply-To: <1478701802-2982-1-git-send-email-tvrtko.ursulin@linux.intel.com>
On Wed, Nov 09, 2016 at 02:30:02PM +0000, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> At the moment we allocate enough sg table entries assuming we
> will not be able to do any coallescing. But since in practice
> we most often can, and more so very effectively, this ends up
> wasting a lot of memory.
>
> A simple and effective way of trimming the over-allocated
> entries is to copy the table over to a new one allocated to the
> exact size.
>
> Experiment on my freshly logged and idle desktop (KDE) showed
Experiments
> that by doing this we can save approximately 1 MiB of RAM, or
> when running a typical benchmark like gl_manhattan I have
> even seen a 6 MiB saving.
More complicated techniques such as only copying the last used page and
freeing the rest are left to the reader.
> v2:
> * Update commit message.
> * Use temporary sg_table on stack. (Chris Wilson)
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d2ad73d0b5b9..411aae535abe 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2232,6 +2232,28 @@ static unsigned int swiotlb_max_size(void)
> #endif
> }
>
> +static void i915_sg_trim(struct sg_table *orig_st)
> +{
> + struct sg_table new_st;
> + struct scatterlist *sg, *new_sg;
> + unsigned int i;
> +
> + if (orig_st->nents == orig_st->orig_nents)
> + return;
> +
> + if (sg_alloc_table(&new_st, orig_st->nents, GFP_KERNEL))
> + return;
> +
> + new_sg = new_st.sgl;
> + for_each_sg(orig_st->sgl, sg, orig_st->nents, i) {
> + sg_set_page(new_sg, sg_page(sg), sg->length, 0);
> + new_sg = sg_next(new_sg);
Worth a
/* called before being DMA mapped, no need to copy sg->dma_* */
?
> + }
> +
> + sg_free_table(orig_st);
> + memcpy(orig_st, &new_st, sizeof(*orig_st));
I would have used *orig_st = new;
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
^ I remembered it this time!
Took a couple of attempts to spell my name right though.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] soc: qcom: Add SoC info driver
From: Geert Uytterhoeven @ 2016-11-09 14:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Arnd Bergmann, Imran Khan, Andy Gross, David Brown, Rob Herring,
Mark Rutland, open list:ARM/QUALCOMM SUPPORT,
open list:ARM/QUALCOMM SUPPORT,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Geert Uytterhoeven
In-Reply-To: <20161102162811.GN25787@tuxbot>
Hi Bjorn,
On Wed, Nov 2, 2016 at 5:28 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Wed 26 Oct 07:05 PDT 2016, Arnd Bergmann wrote:
>> On Wednesday, October 26, 2016 7:20:42 PM CEST Imran Khan wrote:
>> > On 10/26/2016 2:19 AM, Arnd Bergmann wrote:
>> > > On Tuesday, October 25, 2016 3:23:34 PM CEST Imran Khan wrote:
>> > >> On 10/21/2016 4:03 PM, Arnd Bergmann wrote:
>> > >> Okay. I will go for human readable IDs. Can we add 2 more fields
>> > >> in the generic structure.
>> > >> These 2 fields would be:
>> > >>
>> > >> vendor: A string for vendor name
>> > >> serial_number: A string containing serial number for the platform
>> > >
>> > >
>> > > serial_number seems straightforward, adding this seems like a good
>> > > idea. I don't understand yet what would go into the vendor field
>> > > though. For this particular driver, is it always "Qualcomm", or
>> > > would it be a third-party that makes a device based on that chip?
>> >
>> > As we are talking about generic soc_device_attribute fields, I was hoping that
>> > having a vendor field would be helpful as along with family it would provide
>> > a more thorough information. Also as more than one foundries may be used for
>> > a soc, can we have a field say foundry_id to provide this information.
>>
>> My first feeling is that this 'vendor' information can should be
>> derived from the family.
>
> In [1] Geert just put the vendor directly into "family", while Imran
> uses "Snapdragon" (which I find reasonable in the Qualcomm case). But it
> seems like Geert would like a "vendor" as well, rather than a "family".
>
> And if "family" really is supposed to contain the "SoC family name" and
> we're trying to provide user space with some useful information (for
> some reason), should we just rely on the unlikeliness of two vendors
> using the same family name?
>
> [1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1261742.html
I think vendor is slightly less volatile than family. Family may
change overnight
if marketing had a good dream. Well, vendor may change, too...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
* Re: [PATCH] soc: qcom: Add SoC info driver
From: Geert Uytterhoeven @ 2016-11-09 14:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Arnd Bergmann, Imran Khan, Andy Gross, David Brown, Rob Herring,
Mark Rutland, open list:ARM/QUALCOMM SUPPORT,
open list:ARM/QUALCOMM SUPPORT,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Geert Uytterhoeven
In-Reply-To: <20161102162811.GN25787@tuxbot>
Hi Bjorn,
On Wed, Nov 2, 2016 at 5:28 PM, Bjorn Andersson
<bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Wed 26 Oct 07:05 PDT 2016, Arnd Bergmann wrote:
>> On Wednesday, October 26, 2016 7:20:42 PM CEST Imran Khan wrote:
>> > On 10/26/2016 2:19 AM, Arnd Bergmann wrote:
>> > > On Tuesday, October 25, 2016 3:23:34 PM CEST Imran Khan wrote:
>> > >> On 10/21/2016 4:03 PM, Arnd Bergmann wrote:
>> > >> Okay. I will go for human readable IDs. Can we add 2 more fields
>> > >> in the generic structure.
>> > >> These 2 fields would be:
>> > >>
>> > >> vendor: A string for vendor name
>> > >> serial_number: A string containing serial number for the platform
>> > >
>> > >
>> > > serial_number seems straightforward, adding this seems like a good
>> > > idea. I don't understand yet what would go into the vendor field
>> > > though. For this particular driver, is it always "Qualcomm", or
>> > > would it be a third-party that makes a device based on that chip?
>> >
>> > As we are talking about generic soc_device_attribute fields, I was hoping that
>> > having a vendor field would be helpful as along with family it would provide
>> > a more thorough information. Also as more than one foundries may be used for
>> > a soc, can we have a field say foundry_id to provide this information.
>>
>> My first feeling is that this 'vendor' information can should be
>> derived from the family.
>
> In [1] Geert just put the vendor directly into "family", while Imran
> uses "Snapdragon" (which I find reasonable in the Qualcomm case). But it
> seems like Geert would like a "vendor" as well, rather than a "family".
>
> And if "family" really is supposed to contain the "SoC family name" and
> we're trying to provide user space with some useful information (for
> some reason), should we just rely on the unlikeliness of two vendors
> using the same family name?
>
> [1] http://www.mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg1261742.html
I think vendor is slightly less volatile than family. Family may
change overnight
if marketing had a good dream. Well, vendor may change, too...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c
From: Arnaldo Carvalho de Melo @ 2016-11-09 14:44 UTC (permalink / raw)
To: Adrian Hunter
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kernel, Andi Kleen
In-Reply-To: <344fddd4-718b-ecf3-75f0-585eda90df6f@intel.com>
Em Wed, Nov 09, 2016 at 04:01:12PM +0200, Adrian Hunter escreveu:
> On 09/11/16 15:59, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu:
> > +++ b/tools/perf/Documentation/intel-pt.txt
> > @@ -546,6 +546,18 @@ mode by using the --per-thread option.
> > Privileged vs non-privileged users
> > ----------------------------------
> > +The v4.2 kernel introduced support for a context switch metadata event,
> > +PERF_RECORD_SWITCH, which allows unprivileged users to see when their processes
> > +are scheduled out and in, just not by whom, which is left for the
> > +PERF_RECORD_SWITCH_CPU_WIDE, that is only accessible in system wide context,
> > +which in turn requires CAP_SYS_ADMIN.
> > +
> > +Please see the 45ac1403f564 ("perf: Add PERF_RECORD_SWITCH to indicate context
> > +switches") commit, that introduces these metadata events for further info.
> > +
> > +When working with kernels < v4.2, the following considerations must be taken,
> > +as the sched:sched_switch tracepoints will be used to receive such information:
> > +
> > Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users
> > have memory limits imposed upon them. That affects what buffer sizes they can
> > have as outlined above.
> Maybe put that last paragraph about memory limits above the new text.
Ok, adding your Acked-by, it now stands as, please ack:
commit c955ced680270b95a3de6a2434311befaeaea948
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Wed Nov 9 11:04:05 2016 -0300
perf intel-pt: Update documentation about context switch events
Since the unprivileged sched switch event was added in perf, PT doesn't
need need perf_event_paranoid=-1 anymore for per cpu decoding.
Add a note stating that that is only needed for kernels < 4.2.
Reported-by: Andi Kleen <ak@linux.intel.com>
Report-link: http://lkml.kernel.org/r/http://lkml.kernel.org/n/tip-x2ybghpqxxn3zu0m8o7qi42r@git.kernel.org
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: 45ac1403f564 ("perf: Add PERF_RECORD_SWITCH to indicate context switches")
Link: http://lkml.kernel.org/n/tip-x2ybghpqxxn3zu0m8o7qi42r@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
diff --git a/tools/perf/Documentation/intel-pt.txt b/tools/perf/Documentation/intel-pt.txt
index c6c8318e38a2..b0b3007d3c9c 100644
--- a/tools/perf/Documentation/intel-pt.txt
+++ b/tools/perf/Documentation/intel-pt.txt
@@ -550,6 +550,18 @@ Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users
have memory limits imposed upon them. That affects what buffer sizes they can
have as outlined above.
+The v4.2 kernel introduced support for a context switch metadata event,
+PERF_RECORD_SWITCH, which allows unprivileged users to see when their processes
+are scheduled out and in, just not by whom, which is left for the
+PERF_RECORD_SWITCH_CPU_WIDE, that is only accessible in system wide context,
+which in turn requires CAP_SYS_ADMIN.
+
+Please see the 45ac1403f564 ("perf: Add PERF_RECORD_SWITCH to indicate context
+switches") commit, that introduces these metadata events for further info.
+
+When working with kernels < v4.2, the following considerations must be taken,
+as the sched:sched_switch tracepoints will be used to receive such information:
+
Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users are
not permitted to use tracepoints which means there is insufficient side-band
information to decode Intel PT in per-cpu mode, and potentially workload-only
@@ -564,8 +576,11 @@ sched_switch tracepoint
-----------------------
The sched_switch tracepoint is used to provide side-band data for Intel PT
-decoding. sched_switch events are automatically added. e.g. the second event
-shown below
+decoding in kernels where the PERF_RECORD_SWITCH metadata event isn't
+available.
+
+The sched_switch events are automatically added. e.g. the second event shown
+below:
$ perf record -vv -e intel_pt//u uname
------------------------------------------------------------
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.