* Re: [virtio-dev] Re: [PATCH] Add virtio gpu driver.
From: Gerd Hoffmann @ 2015-03-26 11:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtio-dev, open list:ABI/API, Rusty Russell, open list,
open list:DRM DRIVERS, open list:VIRTIO CORE, NET..., Dave Airlie
In-Reply-To: <20150326095736-mutt-send-email-mst@redhat.com>
Hi,
> Absolutely, it's pretty common to mix regions in a BAR.
> For example, we have virtio kick (ioeventfd backed,
> handled in kernel) in same BAR as common and device
> specific configuration.
> We did the same thing you are now doing with the
> virtio BAR, and now we have to maintain two code
> bases, virtio pci config was designed to be future proof
> so why not use it?
It's not about virtio at all. It's about vga compatibility, so we have
a simple framebuffer as boot display. Only used when virtio is *not*
enabled.
> This is mostly just making sure we don't paint ourselves into a corner.
It's a simple memory bar. vga cards have that since pci was invented
(standalone ones, chipset graphics aside), and there havn't been
fundamental changes ...
cheers,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [virtio-dev] Re: [PATCH] Add virtio gpu driver.
From: Michael S. Tsirkin @ 2015-03-26 11:53 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: virtio-dev-sDuHXQ4OtrM4h7I2RyI4rWD2FQJk+8+b, Dave Airlie,
Dave Airlie, David Airlie, Rusty Russell, open list,
open list:DRM DRIVERS, open list:VIRTIO CORE, NET...,
open list:ABI/API
In-Reply-To: <1427369923.9779.18.camel-3OfP5uLMi4C46o+2HkPkLj4oCIwMql/M@public.gmane.org>
On Thu, Mar 26, 2015 at 12:38:43PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > Absolutely, it's pretty common to mix regions in a BAR.
> > For example, we have virtio kick (ioeventfd backed,
> > handled in kernel) in same BAR as common and device
> > specific configuration.
>
> > We did the same thing you are now doing with the
> > virtio BAR, and now we have to maintain two code
> > bases, virtio pci config was designed to be future proof
> > so why not use it?
>
> It's not about virtio at all. It's about vga compatibility, so we have
> a simple framebuffer as boot display. Only used when virtio is *not*
> enabled.
>
I don't know. This seems exactly like the kind of thing
we had in mind when we added the virtio pci capability.
For example, we have text in spec that requires drivers
to skip unknown capabilities.
And yes, if bios pokes at a specific bar then we do
need to list this info in the virtio spec so this makes
it an issue that is virtio related.
> > This is mostly just making sure we don't paint ourselves into a corner.
>
> It's a simple memory bar. vga cards have that since pci was invented
> (standalone ones, chipset graphics aside), and there havn't been
> fundamental changes ...
>
> cheers,
> Gerd
>
Yes, it's not about what we put there now. It's about being able
to move things about in the future without breaking guests.
--
MST
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Christoph Hellwig @ 2015-03-26 11:55 UTC (permalink / raw)
To: Milosz Tanski
Cc: linux-kernel, Christoph Hellwig, linux-fsdevel, linux-aio,
Mel Gorman, Volker Lendecke, Tejun Heo, Jeff Moyer,
Theodore Ts'o, Al Viro, linux-api, Michael Kerrisk,
linux-arch, Dave Chinner, Andrew Morton
In-Reply-To: <cover.1426528417.git.milosz@adfin.com>
On Mon, Mar 16, 2015 at 02:27:10PM -0400, Milosz Tanski wrote:
> This patchset introduces two new syscalls preadv2 and pwritev2. They are the
> same syscalls as preadv and pwrite but with a flag argument. Additionally,
> preadv2 implements an extra RWF_NONBLOCK flag.
There was some arugment that we just don't wait and don't have the
classic unix "blocking" semantics. Maybe it's time to bite the bullet
and rename it to RWF_DONTWAIT? (I personally dont really care).
Second this probably needs to be on top of Al's for-next tree:
https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/log/?h=for-next
Note that this has a flags field in struct kiocb, so we could just use
that for the flags.
Otherwise this version look fine to me, let's get it merged!
Al, are yo ready to pick this up? I'd hate to miss another merge
window.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH v5] Add virtio-input driver.
From: Michael S. Tsirkin @ 2015-03-26 12:10 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: virtio-dev, virtualization, David Herrmann, Dmitry Torokhov,
Rusty Russell, open list, open list:ABI/API
In-Reply-To: <1427366965-32549-1-git-send-email-kraxel@redhat.com>
On Thu, Mar 26, 2015 at 11:49:25AM +0100, Gerd Hoffmann wrote:
> virtio-input is basically evdev-events-over-virtio, so this driver isn't
> much more than reading configuration from config space and forwarding
> incoming events to the linux input layer.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Still a bit worried about using input.h as host/guest
interface (can't we use some formal standard, e.g. USB HID?),
but I'll let Rusty decide that.
Otherwise mostly looks good. One nit below.
> ---
Could you pls include changelog in the future?
You are sending multiple versions per day and it's hard to keep up.
> +static unsigned int features[] = {
> + /* none */
> +};
An empty line wouldn't hurt here about variable definition.
> +static struct virtio_device_id id_table[] = {
> + { VIRTIO_ID_INPUT, VIRTIO_DEV_ANY_ID },
> + { 0 },
> +};
^ permalink raw reply
* Re: [dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area attribute
From: Matt Fleming @ 2015-03-26 13:05 UTC (permalink / raw)
To: Ivan.khoronzhuk
Cc: Matt Fleming, Jean Delvare, Ivan Khoronzhuk, linux-kernel,
ard.biesheuvel, grant.likely, linux-api, linux-doc,
dmidecode-devel, leif.lindholm, msalter
In-Reply-To: <550744E5.3070504@globallogic.com>
On Mon, 16 Mar, at 11:02:29PM, Ivan.khoronzhuk wrote:
>
> Matt, I've sent new patch that replaces this one.
> "[Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs"
> It can take a while to go via review.
OK, thanks Ivan. I've dropped commit ("firmware: dmi-sysfs: Add SMBIOS
entry point area attribute").
The two remaining DMI commits I have are,
59d7e3c02860 firmware: dmi_scan: Use direct access to static vars
d759d96eb5cc firmware: dmi_scan: Use full dmi version for SMBIOS3
Am I still sending those for v4.1?
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply
* Re: [dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area attribute
From: Ivan.khoronzhuk @ 2015-03-26 13:06 UTC (permalink / raw)
To: Matt Fleming
Cc: Matt Fleming, Jean Delvare, Ivan Khoronzhuk, linux-kernel,
ard.biesheuvel, grant.likely, linux-api, linux-doc,
dmidecode-devel, leif.lindholm, msalter
In-Reply-To: <20150326130522.GB6525@codeblueprint.co.uk>
On 26.03.15 15:05, Matt Fleming wrote:
> On Mon, 16 Mar, at 11:02:29PM, Ivan.khoronzhuk wrote:
>> Matt, I've sent new patch that replaces this one.
>> "[Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs"
>> It can take a while to go via review.
> OK, thanks Ivan. I've dropped commit ("firmware: dmi-sysfs: Add SMBIOS
> entry point area attribute").
>
> The two remaining DMI commits I have are,
>
> 59d7e3c02860 firmware: dmi_scan: Use direct access to static vars
> d759d96eb5cc firmware: dmi_scan: Use full dmi version for SMBIOS3
>
> Am I still sending those for v4.1?
>
Yes
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* [PATCH v2 0/3] add cursor blink interval terminal escape sequence
From: Scot Doyle @ 2015-03-26 13:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Michael Kerrisk
Cc: Jiri Slaby, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
Pavel Machek, Geert Uytterhoeven,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150325111949.GA24230-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
v2: Add documentation to console_codes man page (man-pages repo)
This patch series adds an escape sequence to specify the current console's
cursor blink interval. The default interval is set to fbcon's currently
hardcoded 200 msecs.
Scot Doyle (3):
vt: add cursor blink interval escape sequence
fbcon: use the cursor blink interval provided by vt
console_codes.4: Add CSI sequence for cursor blink interval
drivers/tty/vt/vt.c | 9 +++++++++
drivers/video/console/fbcon.c | 10 +++++-----
drivers/video/console/fbcon.h | 1 +
include/linux/console_struct.h | 1 +
man4/console_codes.4 | 1 +
5 files changed, 17 insertions(+), 5 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH v2 1/3] vt: add cursor blink interval escape sequence
From: Scot Doyle @ 2015-03-26 13:54 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Michael Kerrisk, Jiri Slaby, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Pavel Machek,
Geert Uytterhoeven, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.11.1503261341260.2164@local>
Add an escape sequence to specify the current console's cursor blink
interval. The interval is specified as a number of milliseconds until
the next cursor display state toggle, from 50 to 65535. /proc/loadavg
did not show a difference with a one msec interval, but the lower
bound is set to 50 msecs since slower hardware wasn't tested.
Store the interval in the vc_data structure for later access by fbcon,
initializing the value to fbcon's current hardcoded value of 200 msecs.
Signed-off-by: Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org>
Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
---
drivers/tty/vt/vt.c | 9 +++++++++
include/linux/console_struct.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 6e00572..ab1f173 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -135,6 +135,7 @@ const struct consw *conswitchp;
*/
#define DEFAULT_BELL_PITCH 750
#define DEFAULT_BELL_DURATION (HZ/8)
+#define DEFAULT_CURSOR_BLINK_MS 200
struct vc vc_cons [MAX_NR_CONSOLES];
@@ -1590,6 +1591,13 @@ static void setterm_command(struct vc_data *vc)
case 15: /* activate the previous console */
set_console(last_console);
break;
+ case 16: /* set cursor blink duration in msec */
+ if (vc->vc_npar >= 1 && vc->vc_par[1] >= 50 &&
+ vc->vc_par[1] <= USHRT_MAX)
+ vc->vc_cur_blink_ms = vc->vc_par[1];
+ else
+ vc->vc_cur_blink_ms = DEFAULT_CURSOR_BLINK_MS;
+ break;
}
}
@@ -1717,6 +1725,7 @@ static void reset_terminal(struct vc_data *vc, int do_clear)
vc->vc_bell_pitch = DEFAULT_BELL_PITCH;
vc->vc_bell_duration = DEFAULT_BELL_DURATION;
+ vc->vc_cur_blink_ms = DEFAULT_CURSOR_BLINK_MS;
gotoxy(vc, 0, 0);
save_cur(vc);
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index e859c98..e329ee2 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -104,6 +104,7 @@ struct vc_data {
unsigned int vc_resize_user; /* resize request from user */
unsigned int vc_bell_pitch; /* Console bell pitch */
unsigned int vc_bell_duration; /* Console bell duration */
+ unsigned short vc_cur_blink_ms; /* Cursor blink duration */
struct vc_data **vc_display_fg; /* [!] Ptr to var holding fg console for this display */
struct uni_pagedir *vc_uni_pagedir;
struct uni_pagedir **vc_uni_pagedir_loc; /* [!] Location of uni_pagedir variable for this console */
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 14/20] MIPS: KVM: Expose FPU registers
From: Paolo Bonzini @ 2015-03-26 13:55 UTC (permalink / raw)
To: James Hogan, kvm, linux-mips
Cc: Paul Burton, Ralf Baechle, Gleb Natapov, Jonathan Corbet,
linux-api, linux-doc
In-Reply-To: <1426085096-12932-15-git-send-email-james.hogan@imgtec.com>
On 11/03/2015 15:44, James Hogan wrote:
> Add KVM register numbers for the MIPS FPU registers, and implement
> access to them with the KVM_GET_ONE_REG / KVM_SET_ONE_REG ioctls when
> the FPU capability is enabled (exposed in a later patch) and present in
> the guest according to its Config1.FP bit.
>
> The registers are accessible in the current mode of the guest, with each
> sized access showing what the guest would see with an equivalent access,
> and like the architecture they may become UNPREDICTABLE if the FR mode
> is changed. When FR=0, odd doubles are inaccessible as they do not exist
> in that mode.
>
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Paul Burton <paul.burton@imgtec.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Gleb Natapov <gleb@kernel.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-mips@linux-mips.org
> Cc: kvm@vger.kernel.org
> Cc: linux-api@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> ---
> Documentation/virtual/kvm/api.txt | 16 +++++++++
> arch/mips/include/uapi/asm/kvm.h | 37 ++++++++++++++------
> arch/mips/kvm/mips.c | 72 ++++++++++++++++++++++++++++++++++++++-
> 3 files changed, 114 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 1e59515b6d1f..8ba55b9c903e 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -1979,6 +1979,10 @@ registers, find a list below:
> MIPS | KVM_REG_MIPS_COUNT_CTL | 64
> MIPS | KVM_REG_MIPS_COUNT_RESUME | 64
> MIPS | KVM_REG_MIPS_COUNT_HZ | 64
> + MIPS | KVM_REG_MIPS_FPR_32(0..31) | 32
> + MIPS | KVM_REG_MIPS_FPR_64(0..31) | 64
> + MIPS | KVM_REG_MIPS_FCR_IR | 32
> + MIPS | KVM_REG_MIPS_FCR_CSR | 32
>
> ARM registers are mapped using the lower 32 bits. The upper 16 of that
> is the register group type, or coprocessor number:
> @@ -2032,6 +2036,18 @@ patterns depending on whether they're 32-bit or 64-bit registers:
> MIPS KVM control registers (see above) have the following id bit patterns:
> 0x7030 0000 0002 <reg:16>
>
> +MIPS FPU registers (see KVM_REG_MIPS_FPR_{32,64}() above) have the following
> +id bit patterns depending on the size of the register being accessed. They are
> +always accessed according to the current guest FPU mode (Status.FR and
> +Config5.FRE), i.e. as the guest would see them, and they become unpredictable
> +if the guest FPU mode is changed:
> + 0x7020 0000 0003 00 <0:3> <reg:5> (32-bit FPU registers)
> + 0x7030 0000 0003 00 <0:3> <reg:5> (64-bit FPU registers)
> +
> +MIPS FPU control registers (see KVM_REG_MIPS_FCR_{IR,CSR} above) have the
> +following id bit patterns:
> + 0x7020 0000 0003 01 <0:3> <reg:5>
> +
>
> 4.69 KVM_GET_ONE_REG
>
> diff --git a/arch/mips/include/uapi/asm/kvm.h b/arch/mips/include/uapi/asm/kvm.h
> index 75d6d8557e57..401e6a6f8bb8 100644
> --- a/arch/mips/include/uapi/asm/kvm.h
> +++ b/arch/mips/include/uapi/asm/kvm.h
> @@ -36,18 +36,8 @@ struct kvm_regs {
>
> /*
> * for KVM_GET_FPU and KVM_SET_FPU
> - *
> - * If Status[FR] is zero (32-bit FPU), the upper 32-bits of the FPRs
> - * are zero filled.
> */
> struct kvm_fpu {
> - __u64 fpr[32];
> - __u32 fir;
> - __u32 fccr;
> - __u32 fexr;
> - __u32 fenr;
> - __u32 fcsr;
> - __u32 pad;
> };
>
>
> @@ -68,6 +58,8 @@ struct kvm_fpu {
> *
> * Register set = 2: KVM specific registers (see definitions below).
> *
> + * Register set = 3: FPU registers (see definitions below).
> + *
> * Other sets registers may be added in the future. Each set would
> * have its own identifier in bits[31..16].
> */
> @@ -75,6 +67,7 @@ struct kvm_fpu {
> #define KVM_REG_MIPS_GP (KVM_REG_MIPS | 0x0000000000000000ULL)
> #define KVM_REG_MIPS_CP0 (KVM_REG_MIPS | 0x0000000000010000ULL)
> #define KVM_REG_MIPS_KVM (KVM_REG_MIPS | 0x0000000000020000ULL)
> +#define KVM_REG_MIPS_FPU (KVM_REG_MIPS | 0x0000000000030000ULL)
>
>
> /*
> @@ -155,6 +148,30 @@ struct kvm_fpu {
>
>
> /*
> + * KVM_REG_MIPS_FPU - Floating Point registers.
> + *
> + * bits[15..8] - Register subset (see definitions below).
> + * bits[7..5] - Must be zero.
> + * bits[4..0] - Register number within register subset.
> + */
> +
> +#define KVM_REG_MIPS_FPR (KVM_REG_MIPS_FPU | 0x0000000000000000ULL)
> +#define KVM_REG_MIPS_FCR (KVM_REG_MIPS_FPU | 0x0000000000000100ULL)
> +
> +/*
> + * KVM_REG_MIPS_FPR - Floating point / Vector registers.
> + */
> +#define KVM_REG_MIPS_FPR_32(n) (KVM_REG_MIPS_FPR | KVM_REG_SIZE_U32 | (n))
> +#define KVM_REG_MIPS_FPR_64(n) (KVM_REG_MIPS_FPR | KVM_REG_SIZE_U64 | (n))
> +
> +/*
> + * KVM_REG_MIPS_FCR - Floating point control registers.
> + */
> +#define KVM_REG_MIPS_FCR_IR (KVM_REG_MIPS_FCR | KVM_REG_SIZE_U32 | 0)
> +#define KVM_REG_MIPS_FCR_CSR (KVM_REG_MIPS_FCR | KVM_REG_SIZE_U32 | 31)
> +
> +
> +/*
> * KVM MIPS specific structures and definitions
> *
> */
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index dd0833833bea..5e41afe15ae8 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -526,10 +526,13 @@ static int kvm_mips_get_reg(struct kvm_vcpu *vcpu,
> const struct kvm_one_reg *reg)
> {
> struct mips_coproc *cop0 = vcpu->arch.cop0;
> + struct mips_fpu_struct *fpu = &vcpu->arch.fpu;
> int ret;
> s64 v;
> + unsigned int idx;
>
> switch (reg->id) {
> + /* General purpose registers */
> case KVM_REG_MIPS_R0 ... KVM_REG_MIPS_R31:
> v = (long)vcpu->arch.gprs[reg->id - KVM_REG_MIPS_R0];
> break;
> @@ -543,6 +546,38 @@ static int kvm_mips_get_reg(struct kvm_vcpu *vcpu,
> v = (long)vcpu->arch.pc;
> break;
>
> + /* Floating point registers */
> + case KVM_REG_MIPS_FPR_32(0) ... KVM_REG_MIPS_FPR_32(31):
> + if (!kvm_mips_guest_has_fpu(&vcpu->arch))
> + return -EINVAL;
> + idx = reg->id - KVM_REG_MIPS_FPR_32(0);
> + /* Odd singles in top of even double when FR=0 */
> + if (kvm_read_c0_guest_status(cop0) & ST0_FR)
> + v = get_fpr32(&fpu->fpr[idx], 0);
> + else
> + v = get_fpr32(&fpu->fpr[idx & ~1], idx & 1);
> + break;
> + case KVM_REG_MIPS_FPR_64(0) ... KVM_REG_MIPS_FPR_64(31):
> + if (!kvm_mips_guest_has_fpu(&vcpu->arch))
> + return -EINVAL;
> + idx = reg->id - KVM_REG_MIPS_FPR_64(0);
> + /* Can't access odd doubles in FR=0 mode */
> + if (idx & 1 && !(kvm_read_c0_guest_status(cop0) & ST0_FR))
> + return -EINVAL;
> + v = get_fpr64(&fpu->fpr[idx], 0);
> + break;
> + case KVM_REG_MIPS_FCR_IR:
> + if (!kvm_mips_guest_has_fpu(&vcpu->arch))
> + return -EINVAL;
> + v = boot_cpu_data.fpu_id;
> + break;
> + case KVM_REG_MIPS_FCR_CSR:
> + if (!kvm_mips_guest_has_fpu(&vcpu->arch))
> + return -EINVAL;
> + v = fpu->fcr31;
> + break;
> +
> + /* Co-processor 0 registers */
> case KVM_REG_MIPS_CP0_INDEX:
> v = (long)kvm_read_c0_guest_index(cop0);
> break;
> @@ -636,7 +671,9 @@ static int kvm_mips_set_reg(struct kvm_vcpu *vcpu,
> const struct kvm_one_reg *reg)
> {
> struct mips_coproc *cop0 = vcpu->arch.cop0;
> - u64 v;
> + struct mips_fpu_struct *fpu = &vcpu->arch.fpu;
> + s64 v;
> + unsigned int idx;
>
> if ((reg->id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U64) {
> u64 __user *uaddr64 = (u64 __user *)(long)reg->addr;
> @@ -655,6 +692,7 @@ static int kvm_mips_set_reg(struct kvm_vcpu *vcpu,
> }
>
> switch (reg->id) {
> + /* General purpose registers */
> case KVM_REG_MIPS_R0:
> /* Silently ignore requests to set $0 */
> break;
> @@ -671,6 +709,38 @@ static int kvm_mips_set_reg(struct kvm_vcpu *vcpu,
> vcpu->arch.pc = v;
> break;
>
> + /* Floating point registers */
> + case KVM_REG_MIPS_FPR_32(0) ... KVM_REG_MIPS_FPR_32(31):
> + if (!kvm_mips_guest_has_fpu(&vcpu->arch))
> + return -EINVAL;
> + idx = reg->id - KVM_REG_MIPS_FPR_32(0);
> + /* Odd singles in top of even double when FR=0 */
> + if (kvm_read_c0_guest_status(cop0) & ST0_FR)
> + set_fpr32(&fpu->fpr[idx], 0, v);
> + else
> + set_fpr32(&fpu->fpr[idx & ~1], idx & 1, v);
> + break;
> + case KVM_REG_MIPS_FPR_64(0) ... KVM_REG_MIPS_FPR_64(31):
> + if (!kvm_mips_guest_has_fpu(&vcpu->arch))
> + return -EINVAL;
> + idx = reg->id - KVM_REG_MIPS_FPR_64(0);
> + /* Can't access odd doubles in FR=0 mode */
> + if (idx & 1 && !(kvm_read_c0_guest_status(cop0) & ST0_FR))
> + return -EINVAL;
> + set_fpr64(&fpu->fpr[idx], 0, v);
> + break;
> + case KVM_REG_MIPS_FCR_IR:
> + if (!kvm_mips_guest_has_fpu(&vcpu->arch))
> + return -EINVAL;
> + /* Read-only */
> + break;
> + case KVM_REG_MIPS_FCR_CSR:
> + if (!kvm_mips_guest_has_fpu(&vcpu->arch))
> + return -EINVAL;
> + fpu->fcr31 = v;
> + break;
> +
> + /* Co-processor 0 registers */
> case KVM_REG_MIPS_CP0_INDEX:
> kvm_write_c0_guest_index(cop0, v);
> break;
>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
^ permalink raw reply
* [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Scot Doyle @ 2015-03-26 13:56 UTC (permalink / raw)
To: Greg Kroah-Hartman, Tomi Valkeinen
Cc: Michael Kerrisk, Jiri Slaby, Jean-Christophe Plagniol-Villard,
Pavel Machek, Geert Uytterhoeven,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.11.1503261341260.2164@local>
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org>
Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
---
drivers/video/console/fbcon.c | 10 +++++-----
drivers/video/console/fbcon.h | 1 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index b972106..05b1d1a 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -402,7 +402,7 @@ static void cursor_timer_handler(unsigned long dev_addr)
struct fbcon_ops *ops = info->fbcon_par;
queue_work(system_power_efficient_wq, &info->queue);
- mod_timer(&ops->cursor_timer, jiffies + HZ/5);
+ mod_timer(&ops->cursor_timer, jiffies + ops->cur_blink_jiffies);
}
static void fbcon_add_cursor_timer(struct fb_info *info)
@@ -417,7 +417,7 @@ static void fbcon_add_cursor_timer(struct fb_info *info)
init_timer(&ops->cursor_timer);
ops->cursor_timer.function = cursor_timer_handler;
- ops->cursor_timer.expires = jiffies + HZ / 5;
+ ops->cursor_timer.expires = jiffies + ops->cur_blink_jiffies;
ops->cursor_timer.data = (unsigned long ) info;
add_timer(&ops->cursor_timer);
ops->flags |= FBCON_FLAGS_CURSOR_TIMER;
@@ -1309,9 +1309,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
if (fbcon_is_inactive(vc, info) || vc->vc_deccm != 1)
return;
- if (vc->vc_cursor_type & 0x10)
- fbcon_del_cursor_timer(info);
- else
+ ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
+ fbcon_del_cursor_timer(info);
+ if (!(vc->vc_cursor_type & 0x10))
fbcon_add_cursor_timer(info);
ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
diff --git a/drivers/video/console/fbcon.h b/drivers/video/console/fbcon.h
index 6bd2e0c..7aaa4ea 100644
--- a/drivers/video/console/fbcon.h
+++ b/drivers/video/console/fbcon.h
@@ -70,6 +70,7 @@ struct fbcon_ops {
struct fb_cursor cursor_state;
struct display *p;
int currcon; /* Current VC. */
+ int cur_blink_jiffies;
int cursor_flash;
int cursor_reset;
int blank_state;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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 related
* [PATCH v2 3/3] console_codes.4: Add CSI sequence for cursor blink interval
From: Scot Doyle @ 2015-03-26 13:57 UTC (permalink / raw)
To: Michael Kerrisk
Cc: Greg Kroah-Hartman, Jiri Slaby, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Pavel Machek,
Geert Uytterhoeven, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.11.1503261341260.2164@local>
Add a Console Private CSI sequence to specify the current console's
cursor blink interval. The interval is specified as a number of
milliseconds until the next cursor display state toggle, from 50 to
65535.
Signed-off-by: Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org>
---
man4/console_codes.4 | 1 +
1 file changed, 1 insertion(+)
diff --git a/man4/console_codes.4 b/man4/console_codes.4
index 34f7535..7d05076 100644
--- a/man4/console_codes.4
+++ b/man4/console_codes.4
@@ -377,6 +377,7 @@ ESC [ 15 ] T{
Bring the previous console to the front
(since Linux 2.6.0).
T}
+ESC [ 16 ; \fIn\fP ] Set the cursor blink interval in milliseconds.
.TE
.SS Character sets
The kernel knows about 4 translations of bytes into console-screen
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 20/20] MIPS: KVM: Wire up MSA capability
From: Paolo Bonzini @ 2015-03-26 13:58 UTC (permalink / raw)
To: James Hogan, kvm, linux-mips
Cc: Ralf Baechle, Gleb Natapov, Jonathan Corbet, linux-api, linux-doc
In-Reply-To: <1426085096-12932-21-git-send-email-james.hogan@imgtec.com>
On 11/03/2015 15:44, James Hogan wrote:
> Now that the code is in place for KVM to support MIPS SIMD Architecutre
> (MSA) in MIPS guests, wire up the new KVM_CAP_MIPS_MSA capability.
>
> For backwards compatibility, the capability must be explicitly enabled
> in order to detect or make use of MSA from the guest.
>
> The capability is not supported if the hardware supports MSA vector
> partitioning, since the extra support cannot be tested yet and it
> extends the state that the userland program would have to save.
>
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Gleb Natapov <gleb@kernel.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-mips@linux-mips.org
> Cc: kvm@vger.kernel.org
> Cc: linux-api@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> ---
> Documentation/virtual/kvm/api.txt | 12 ++++++++++++
> arch/mips/kvm/mips.c | 24 ++++++++++++++++++++++++
> include/uapi/linux/kvm.h | 1 +
> 3 files changed, 37 insertions(+)
>
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 47ddf0475211..97dd9ee69ca8 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -3224,6 +3224,18 @@ done the KVM_REG_MIPS_FPR_* and KVM_REG_MIPS_FCR_* registers can be accessed
> Config5.FRE bits are accessible via the KVM API and also from the guest,
> depending on them being supported by the FPU.
>
> +6.10 KVM_CAP_MIPS_MSA
> +
> +Architectures: mips
> +Target: vcpu
> +Parameters: args[0] is reserved for future use (should be 0).
> +
> +This capability allows the use of the MIPS SIMD Architecture (MSA) by the guest.
> +It allows the Config3.MSAP bit to be set to enable the use of MSA by the guest.
> +Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
> +accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
> +the guest.
> +
> 7. Capabilities that can be enabled on VMs
> ------------------------------------------
>
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index 9319c4360285..3b3530f493eb 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -880,6 +880,15 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
> return -EINVAL;
> vcpu->arch.fpu_enabled = true;
> break;
> + case KVM_CAP_MIPS_MSA:
> + /*
> + * MSA vector partitioning not supported,
> + * see kvm_vm_ioctl_check_extension().
> + */
> + if (!cpu_has_msa || boot_cpu_data.msa_id & MSA_IR_WRPF)
> + return -EINVAL;
Perhaps you can call kvm_vm_ioctl_check_extension directly, outside the
switch (it's okay if it's called for a capability other than FPU and MSA)?
Apart from this nit,
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo
> + vcpu->arch.msa_enabled = true;
> + break;
> default:
> r = -EINVAL;
> break;
> @@ -1071,6 +1080,21 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> case KVM_CAP_MIPS_FPU:
> r = !!cpu_has_fpu;
> break;
> + case KVM_CAP_MIPS_MSA:
> + /*
> + * We don't support MSA vector partitioning yet:
> + * 1) It would require explicit support which can't be tested
> + * yet due to lack of support in current hardware.
> + * 2) It extends the state that would need to be saved/restored
> + * by e.g. QEMU for migration.
> + *
> + * When vector partitioning hardware becomes available, support
> + * could be added by requiring a flag when enabling
> + * KVM_CAP_MIPS_MSA capability to indicate that userland knows
> + * to save/restore the appropriate extra state.
> + */
> + r = cpu_has_msa && !(boot_cpu_data.msa_id & MSA_IR_WRPF);
> + break;
> default:
> r = 0;
> break;
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 98f6e5c653ff..5f859888e3ad 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -761,6 +761,7 @@ struct kvm_ppc_smmu_info {
> #define KVM_CAP_CHECK_EXTENSION_VM 105
> #define KVM_CAP_S390_USER_SIGP 106
> #define KVM_CAP_MIPS_FPU 107
> +#define KVM_CAP_MIPS_MSA 108
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
>
^ permalink raw reply
* Re: [dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area attribute
From: Jean Delvare @ 2015-03-26 14:23 UTC (permalink / raw)
To: Ivan.khoronzhuk
Cc: Matt Fleming, Matt Fleming, Ivan Khoronzhuk,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
dmidecode-devel-qX2TKyscuCcdnm+yROfE0A,
leif.lindholm-QSEj5FYQhm4dnm+yROfE0A,
msalter-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <55140442.6010102-hExfYMNmJl/Cnp4W7fqMDg@public.gmane.org>
Le Thursday 26 March 2015 à 15:06 +0200, Ivan.khoronzhuk a écrit :
>
> On 26.03.15 15:05, Matt Fleming wrote:
> > On Mon, 16 Mar, at 11:02:29PM, Ivan.khoronzhuk wrote:
> >> Matt, I've sent new patch that replaces this one.
> >> "[Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs"
> >> It can take a while to go via review.
> > OK, thanks Ivan. I've dropped commit ("firmware: dmi-sysfs: Add SMBIOS
> > entry point area attribute").
> >
> > The two remaining DMI commits I have are,
> >
> > 59d7e3c02860 firmware: dmi_scan: Use direct access to static vars
> > d759d96eb5cc firmware: dmi_scan: Use full dmi version for SMBIOS3
> >
> > Am I still sending those for v4.1?
FWIW I have still not reviewed these, I would like to, but my current
health condition make my progress slower than usual :/
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: [PATCH 20/20] MIPS: KVM: Wire up MSA capability
From: James Hogan @ 2015-03-26 14:52 UTC (permalink / raw)
To: Paolo Bonzini, kvm, linux-mips
Cc: Ralf Baechle, Gleb Natapov, Jonathan Corbet, linux-api, linux-doc
In-Reply-To: <5514108F.9060905@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4602 bytes --]
On 26/03/15 13:58, Paolo Bonzini wrote:
>
>
> On 11/03/2015 15:44, James Hogan wrote:
>> Now that the code is in place for KVM to support MIPS SIMD Architecutre
>> (MSA) in MIPS guests, wire up the new KVM_CAP_MIPS_MSA capability.
>>
>> For backwards compatibility, the capability must be explicitly enabled
>> in order to detect or make use of MSA from the guest.
>>
>> The capability is not supported if the hardware supports MSA vector
>> partitioning, since the extra support cannot be tested yet and it
>> extends the state that the userland program would have to save.
>>
>> Signed-off-by: James Hogan <james.hogan@imgtec.com>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: Ralf Baechle <ralf@linux-mips.org>
>> Cc: Gleb Natapov <gleb@kernel.org>
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> Cc: linux-mips@linux-mips.org
>> Cc: kvm@vger.kernel.org
>> Cc: linux-api@vger.kernel.org
>> Cc: linux-doc@vger.kernel.org
>> Signed-off-by: James Hogan <james.hogan@imgtec.com>
>> ---
>> Documentation/virtual/kvm/api.txt | 12 ++++++++++++
>> arch/mips/kvm/mips.c | 24 ++++++++++++++++++++++++
>> include/uapi/linux/kvm.h | 1 +
>> 3 files changed, 37 insertions(+)
>>
>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>> index 47ddf0475211..97dd9ee69ca8 100644
>> --- a/Documentation/virtual/kvm/api.txt
>> +++ b/Documentation/virtual/kvm/api.txt
>> @@ -3224,6 +3224,18 @@ done the KVM_REG_MIPS_FPR_* and KVM_REG_MIPS_FCR_* registers can be accessed
>> Config5.FRE bits are accessible via the KVM API and also from the guest,
>> depending on them being supported by the FPU.
>>
>> +6.10 KVM_CAP_MIPS_MSA
>> +
>> +Architectures: mips
>> +Target: vcpu
>> +Parameters: args[0] is reserved for future use (should be 0).
>> +
>> +This capability allows the use of the MIPS SIMD Architecture (MSA) by the guest.
>> +It allows the Config3.MSAP bit to be set to enable the use of MSA by the guest.
>> +Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
>> +accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
>> +the guest.
>> +
>> 7. Capabilities that can be enabled on VMs
>> ------------------------------------------
>>
>> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
>> index 9319c4360285..3b3530f493eb 100644
>> --- a/arch/mips/kvm/mips.c
>> +++ b/arch/mips/kvm/mips.c
>> @@ -880,6 +880,15 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
>> return -EINVAL;
>> vcpu->arch.fpu_enabled = true;
>> break;
>> + case KVM_CAP_MIPS_MSA:
>> + /*
>> + * MSA vector partitioning not supported,
>> + * see kvm_vm_ioctl_check_extension().
>> + */
>> + if (!cpu_has_msa || boot_cpu_data.msa_id & MSA_IR_WRPF)
>> + return -EINVAL;
>
> Perhaps you can call kvm_vm_ioctl_check_extension directly, outside the
> switch (it's okay if it's called for a capability other than FPU and MSA)?
Yes, good idea. That works nicely.
>
> Apart from this nit,
>
> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
>
> Paolo
Thanks!
James
>
>> + vcpu->arch.msa_enabled = true;
>> + break;
>> default:
>> r = -EINVAL;
>> break;
>> @@ -1071,6 +1080,21 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>> case KVM_CAP_MIPS_FPU:
>> r = !!cpu_has_fpu;
>> break;
>> + case KVM_CAP_MIPS_MSA:
>> + /*
>> + * We don't support MSA vector partitioning yet:
>> + * 1) It would require explicit support which can't be tested
>> + * yet due to lack of support in current hardware.
>> + * 2) It extends the state that would need to be saved/restored
>> + * by e.g. QEMU for migration.
>> + *
>> + * When vector partitioning hardware becomes available, support
>> + * could be added by requiring a flag when enabling
>> + * KVM_CAP_MIPS_MSA capability to indicate that userland knows
>> + * to save/restore the appropriate extra state.
>> + */
>> + r = cpu_has_msa && !(boot_cpu_data.msa_id & MSA_IR_WRPF);
>> + break;
>> default:
>> r = 0;
>> break;
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index 98f6e5c653ff..5f859888e3ad 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -761,6 +761,7 @@ struct kvm_ppc_smmu_info {
>> #define KVM_CAP_CHECK_EXTENSION_VM 105
>> #define KVM_CAP_S390_USER_SIGP 106
>> #define KVM_CAP_MIPS_FPU 107
>> +#define KVM_CAP_MIPS_MSA 108
>>
>> #ifdef KVM_CAP_IRQ_ROUTING
>>
>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [virtio-dev] Re: [PATCH] Add virtio gpu driver.
From: Gerd Hoffmann @ 2015-03-26 15:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtio-dev, open list:ABI/API, Rusty Russell, open list,
open list:DRM DRIVERS, open list:VIRTIO CORE, NET..., Dave Airlie
In-Reply-To: <20150326124751-mutt-send-email-mst@redhat.com>
Hi,
> I don't know. This seems exactly like the kind of thing
> we had in mind when we added the virtio pci capability.
> For example, we have text in spec that requires drivers
> to skip unknown capabilities.
>
> And yes, if bios pokes at a specific bar then we do
> need to list this info in the virtio spec so this makes
> it an issue that is virtio related.
Hmm, virtio-vga is a two-in-one device basically. When virtio is
enabled it behaves like virtio-gpu-pci, otherwise it behaves very
simliar to stdvga. So you need to know nothing about virtio to handle
the vga side, and I want keep it that way.
When no vga compatibility is needed there always is the option to just
use virtio-gpu-pci instead.
> Yes, it's not about what we put there now. It's about being able
> to move things about in the future without breaking guests.
We don't have that today for stdvga, and I still fail to see what this
buys us.
Completely different thing crossing my mind: I think we can make
virtio-vga fully compatible with stdvga. stdvga has two bars, memory
(#0) and mmio (#2). We can make the mmio bar larger and place all the
virtio regions there.
I think in any case I'll go split off the vga compatibility bits to a
different patch (and possible a separate patch series).
cheers,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver
From: Russell King - ARM Linux @ 2015-03-26 15:46 UTC (permalink / raw)
To: Peter Hurley
Cc: Maxime Coquelin, u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
afaerber-l3A5Bk7waGM, geert-Td1EMuHUCqxL1ZNQvxDV9g, Rob Herring,
Philipp Zabel, Linus Walleij, Arnd Bergmann, stefan-XLVq0VzYD2Y,
pmeerw-jW+XmwGofnusTnJN9+BGXg, pebolle-IWqWACnzNjzz+pZb47iToQ,
Jonathan Corbet, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Daniel Lezcano, Thomas Gleixner, Greg Kroah-Hartman,
Jiri Slaby, Andrew Morton, David S. Miller, Mauro Carvalho Chehab,
Joe Perches, Antti Palosaari, Tejun Heo
In-Reply-To: <5511ABAA.2010303-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>
On Tue, Mar 24, 2015 at 02:23:38PM -0400, Peter Hurley wrote:
> Hi Maxime,
>
> On 03/12/2015 05:55 PM, Maxime Coquelin wrote:
> > +static unsigned int stm32_get_mctrl(struct uart_port *port)
> > +{
> > + /*
> > + * This routine is used for geting signals of: DTR, DCD, DSR, RI,
> > + * and CTS/RTS
It's also worth noting that this comment is wrong. This is used to get
the state of DCD, DSR, RI and CTS. DTR and RTS are *not* included
because the core tracks their state.
...
> > + stm32port->clk = devm_clk_get(&pdev->dev, NULL);
> > +
> > + if (WARN_ON(IS_ERR(stm32port->clk)))
>
> Do you really need a stack trace here? Could this be dev_err() instead?
>
> > + return -EINVAL;
Also, propagate the error code.
> > +
> > + /* ensure that clk rate is correct by enabling the clk */
> > + clk_prepare_enable(stm32port->clk);
And remember to check the return value of clk_prepare_enable().
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 00/20] MIPS: KVM: Guest FPU & SIMD (MSA) support
From: James Hogan @ 2015-03-26 16:08 UTC (permalink / raw)
To: Paolo Bonzini, kvm, linux-mips
Cc: James Hogan, Paul Burton, Ralf Baechle, Gleb Natapov,
Jonathan Corbet, linux-api, linux-doc
This patchset primarily adds guest Floating Point Unit (FPU) and MIPS
SIMD Architecture (MSA) support to MIPS KVM, by enabling the host
FPU/MSA while in guest mode.
This patchset depends on Paul Burton's FP/MSA fixes patchset, which will
make it into 4.0. I've only included the 3 patches (15, 19, 20) that
have changed since v1, which can be found here:
http://thread.gmane.org/gmane.linux.kernel.api/8984
The corresponding QEMU patchset can be found here:
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/134314
Assuming there are no further review comments I'll submit a pull request
once Ralf has applied the FP/MSA fixes for me to merge.
Changes in v2:
- Add missing MSA vector and control register id bit patterns to API
documentation.
- Rebased on KVM queue (KVM_CAP_MIPS_FPU & KVM_CAP_MIPS_MSA increased to
108 & 109 after KVM_CAP_S390_VECTOR_REGISTERS took 107).
- Just call kvm_vm_ioctl_check_extension() from
kvm_vcpu_ioctl_enable_cap() rather than duplicating the extension
presence conditions (Paolo).
Original description:
- Adds KVM_CAP_MIPS_FPU and KVM_CAP_MIPS_MSA capabilities which must be
enabled to add FPU/MSA to the guest.
- Supports FR=0, FR=1, FRE=1 floating point register modes and 128-bit
vector registers.
- Does not support UFR/UFE (guest user control of FR/FRE bits), or MSA
vector partitioning.
- Context restore is lazy: done on first actual use.
- Context save is lazy: once restored, host FPU/MSA gets
enabled/disabled when guest enables/disables it, with registers left
loaded as long as possible.
- So the state that can be loaded at any one time is:
- No FPRs/vector state
- FR=0 FPRs (change of FR discards FP state)
- FR=1 FPRs
- Vector state (includes FR=1 FPRs)
- Vector state only (when guest CU1=0, FR=0)
- FCSR/MSACSR status registers are saved/restored around guest
execution, since care must be taken to handle FP exceptions when
writing these registers.
The patches are arranged roughly in groups:
- Patch 1 is a related minimal stable fix which can be applied in
advance of the others (patch 18 fills it out a bit).
- Patch 2 is a generic MIPS change required to be able to restore
FCSR/MSACSR registers with exceptions pending.
- Patches 3..10 add various misc KVM improvements and cleanups, most of
which the later patches depend on.
- Patches 11..15 add the main guest FPU support.
- Patches 16..20 add the main guest MSA support (structured like 11.15).
James Hogan (20):
MIPS: KVM: Handle MSA Disabled exceptions from guest
MIPS: Clear [MSA]FPE CSR.Cause after notify_die()
MIPS: KVM: Handle TRAP exceptions from guest kernel
MIPS: KVM: Implement PRid CP0 register access
MIPS: KVM: Sort kvm_mips_get_reg() registers
MIPS: KVM: Drop pr_info messages on init/exit
MIPS: KVM: Clean up register definitions a little
MIPS: KVM: Simplify default guest Config registers
MIPS: KVM: Add Config4/5 and writing of Config registers
MIPS: KVM: Add vcpu_get_regs/vcpu_set_regs callback
MIPS: KVM: Add base guest FPU support
MIPS: KVM: Emulate FPU bits in COP0 interface
MIPS: KVM: Add FP exception handling
MIPS: KVM: Expose FPU registers
MIPS: KVM: Wire up FPU capability
MIPS: KVM: Add base guest MSA support
MIPS: KVM: Emulate MSA bits in COP0 interface
MIPS: KVM: Add MSA exception handling
MIPS: KVM: Expose MSA registers
MIPS: KVM: Wire up MSA capability
Documentation/virtual/kvm/api.txt | 54 +++++
arch/mips/include/asm/kdebug.h | 3 +-
arch/mips/include/asm/kvm_host.h | 125 +++++++---
arch/mips/include/uapi/asm/kvm.h | 160 ++++++++-----
arch/mips/kernel/asm-offsets.c | 39 ++++
arch/mips/kernel/genex.S | 14 +-
arch/mips/kernel/traps.c | 16 +-
arch/mips/kvm/Makefile | 8 +-
arch/mips/kvm/emulate.c | 332 ++++++++++++++++++++++++++-
arch/mips/kvm/fpu.S | 122 ++++++++++
arch/mips/kvm/locore.S | 38 +++
arch/mips/kvm/mips.c | 472 +++++++++++++++++++++++++++++++++++++-
arch/mips/kvm/msa.S | 161 +++++++++++++
arch/mips/kvm/stats.c | 4 +
arch/mips/kvm/tlb.c | 6 +
arch/mips/kvm/trap_emul.c | 199 +++++++++++++++-
include/uapi/linux/kvm.h | 2 +
17 files changed, 1631 insertions(+), 124 deletions(-)
create mode 100644 arch/mips/kvm/fpu.S
create mode 100644 arch/mips/kvm/msa.S
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Gleb Natapov <gleb@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc: linux-api@vger.kernel.org
Cc: linux-doc@vger.kernel.org
--
2.0.5
^ permalink raw reply
* [PATCH v2 15/20] MIPS: KVM: Wire up FPU capability
From: James Hogan @ 2015-03-26 16:08 UTC (permalink / raw)
To: Paolo Bonzini, kvm, linux-mips
Cc: James Hogan, Ralf Baechle, Gleb Natapov, Jonathan Corbet,
linux-api, linux-doc
In-Reply-To: <1427386113-30515-1-git-send-email-james.hogan@imgtec.com>
Now that the code is in place for KVM to support FPU in MIPS KVM guests,
wire up the new KVM_CAP_MIPS_FPU capability.
For backwards compatibility, the capability must be explicitly enabled
in order to detect or make use of the FPU from the guest.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Gleb Natapov <gleb@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc: linux-api@vger.kernel.org
Cc: linux-doc@vger.kernel.org
---
Changes in v2:
- Rebased on KVM queue (KVM_CAP_MIPS_FPU increased to 108 after
KVM_CAP_S390_VECTOR_REGISTERS took 107).
- Just call kvm_vm_ioctl_check_extension() from
kvm_vcpu_ioctl_enable_cap() rather than duplicating the extension
presence condition (Paolo).
---
Documentation/virtual/kvm/api.txt | 13 +++++++++++++
arch/mips/kvm/mips.c | 37 +++++++++++++++++++++++++++++++++++++
include/uapi/linux/kvm.h | 1 +
3 files changed, 51 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index c666c375688e..c95134160843 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3208,6 +3208,19 @@ Parameters: none
This capability enables the in-kernel irqchip for s390. Please refer to
"4.24 KVM_CREATE_IRQCHIP" for details.
+6.9 KVM_CAP_MIPS_FPU
+
+Architectures: mips
+Target: vcpu
+Parameters: args[0] is reserved for future use (should be 0).
+
+This capability allows the use of the host Floating Point Unit by the guest. It
+allows the Config1.FP bit to be set to enable the FPU in the guest. Once this is
+done the KVM_REG_MIPS_FPR_* and KVM_REG_MIPS_FCR_* registers can be accessed
+(depending on the current guest FPU register mode), and the Status.FR,
+Config5.FRE bits are accessible via the KVM API and also from the guest,
+depending on them being supported by the FPU.
+
7. Capabilities that can be enabled on VMs
------------------------------------------
diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index 5e41afe15ae8..7f86cb73d05d 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -797,6 +797,30 @@ static int kvm_mips_set_reg(struct kvm_vcpu *vcpu,
return 0;
}
+static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
+ struct kvm_enable_cap *cap)
+{
+ int r = 0;
+
+ if (!kvm_vm_ioctl_check_extension(vcpu->kvm, cap->cap))
+ return -EINVAL;
+ if (cap->flags)
+ return -EINVAL;
+ if (cap->args[0])
+ return -EINVAL;
+
+ switch (cap->cap) {
+ case KVM_CAP_MIPS_FPU:
+ vcpu->arch.fpu_enabled = true;
+ break;
+ default:
+ r = -EINVAL;
+ break;
+ }
+
+ return r;
+}
+
long kvm_arch_vcpu_ioctl(struct file *filp, unsigned int ioctl,
unsigned long arg)
{
@@ -854,6 +878,15 @@ long kvm_arch_vcpu_ioctl(struct file *filp, unsigned int ioctl,
r = kvm_vcpu_ioctl_interrupt(vcpu, &irq);
break;
}
+ case KVM_ENABLE_CAP: {
+ struct kvm_enable_cap cap;
+
+ r = -EFAULT;
+ if (copy_from_user(&cap, argp, sizeof(cap)))
+ goto out;
+ r = kvm_vcpu_ioctl_enable_cap(vcpu, &cap);
+ break;
+ }
default:
r = -ENOIOCTLCMD;
}
@@ -962,11 +995,15 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
switch (ext) {
case KVM_CAP_ONE_REG:
+ case KVM_CAP_ENABLE_CAP:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
r = KVM_COALESCED_MMIO_PAGE_OFFSET;
break;
+ case KVM_CAP_MIPS_FPU:
+ r = !!cpu_has_fpu;
+ break;
default:
r = 0;
break;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 82634a492fe0..0670cf4337d6 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -761,6 +761,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_CHECK_EXTENSION_VM 105
#define KVM_CAP_S390_USER_SIGP 106
#define KVM_CAP_S390_VECTOR_REGISTERS 107
+#define KVM_CAP_MIPS_FPU 108
#ifdef KVM_CAP_IRQ_ROUTING
--
2.0.5
^ permalink raw reply related
* [PATCH v2 19/20] MIPS: KVM: Expose MSA registers
From: James Hogan @ 2015-03-26 16:08 UTC (permalink / raw)
To: Paolo Bonzini, kvm-u79uwXL29TY76Z2rM5mHXA,
linux-mips-6z/3iImG2C8G8FEW9MqTrA
Cc: James Hogan, Paul Burton, Ralf Baechle, Gleb Natapov,
Jonathan Corbet, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1427386113-30515-1-git-send-email-james.hogan-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
Add KVM register numbers for the MIPS SIMD Architecture (MSA) registers,
and implement access to them with the KVM_GET_ONE_REG / KVM_SET_ONE_REG
ioctls when the MSA capability is enabled (exposed in a later patch) and
present in the guest according to its Config3.MSAP bit.
The MSA vector registers use the same register numbers as the FPU
registers except with a different size (128bits). Since MSA depends on
Status.FR=1, these registers are inaccessible when Status.FR=0. These
registers are returned as a single native endian 128bit value, rather
than least significant half first with each 64-bit half native endian as
the kernel uses internally.
Signed-off-by: James Hogan <james.hogan-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
Cc: Paolo Bonzini <pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Paul Burton <paul.burton-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
Cc: Ralf Baechle <ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>
Cc: Gleb Natapov <gleb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org
Cc: kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
Changes in v2:
- Add missing MSA vector and control register id bit patterns to API
documentation.
---
Documentation/virtual/kvm/api.txt | 12 +++++++-
arch/mips/include/uapi/asm/kvm.h | 12 ++++++--
arch/mips/kvm/mips.c | 65 +++++++++++++++++++++++++++++++++++++++
3 files changed, 86 insertions(+), 3 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index c95134160843..e50cbb56272b 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1981,8 +1981,11 @@ registers, find a list below:
MIPS | KVM_REG_MIPS_COUNT_HZ | 64
MIPS | KVM_REG_MIPS_FPR_32(0..31) | 32
MIPS | KVM_REG_MIPS_FPR_64(0..31) | 64
+ MIPS | KVM_REG_MIPS_VEC_128(0..31) | 128
MIPS | KVM_REG_MIPS_FCR_IR | 32
MIPS | KVM_REG_MIPS_FCR_CSR | 32
+ MIPS | KVM_REG_MIPS_MSA_IR | 32
+ MIPS | KVM_REG_MIPS_MSA_CSR | 32
ARM registers are mapped using the lower 32 bits. The upper 16 of that
is the register group type, or coprocessor number:
@@ -2040,14 +2043,21 @@ MIPS FPU registers (see KVM_REG_MIPS_FPR_{32,64}() above) have the following
id bit patterns depending on the size of the register being accessed. They are
always accessed according to the current guest FPU mode (Status.FR and
Config5.FRE), i.e. as the guest would see them, and they become unpredictable
-if the guest FPU mode is changed:
+if the guest FPU mode is changed. MIPS SIMD Architecture (MSA) vector
+registers (see KVM_REG_MIPS_VEC_128() above) have similar patterns as they
+overlap the FPU registers:
0x7020 0000 0003 00 <0:3> <reg:5> (32-bit FPU registers)
0x7030 0000 0003 00 <0:3> <reg:5> (64-bit FPU registers)
+ 0x7040 0000 0003 00 <0:3> <reg:5> (128-bit MSA vector registers)
MIPS FPU control registers (see KVM_REG_MIPS_FCR_{IR,CSR} above) have the
following id bit patterns:
0x7020 0000 0003 01 <0:3> <reg:5>
+MIPS MSA control registers (see KVM_REG_MIPS_MSA_{IR,CSR} above) have the
+following id bit patterns:
+ 0x7020 0000 0003 02 <0:3> <reg:5>
+
4.69 KVM_GET_ONE_REG
diff --git a/arch/mips/include/uapi/asm/kvm.h b/arch/mips/include/uapi/asm/kvm.h
index 401e6a6f8bb8..6985eb59b085 100644
--- a/arch/mips/include/uapi/asm/kvm.h
+++ b/arch/mips/include/uapi/asm/kvm.h
@@ -58,7 +58,7 @@ struct kvm_fpu {
*
* Register set = 2: KVM specific registers (see definitions below).
*
- * Register set = 3: FPU registers (see definitions below).
+ * Register set = 3: FPU / MSA registers (see definitions below).
*
* Other sets registers may be added in the future. Each set would
* have its own identifier in bits[31..16].
@@ -148,7 +148,7 @@ struct kvm_fpu {
/*
- * KVM_REG_MIPS_FPU - Floating Point registers.
+ * KVM_REG_MIPS_FPU - Floating Point and MIPS SIMD Architecture (MSA) registers.
*
* bits[15..8] - Register subset (see definitions below).
* bits[7..5] - Must be zero.
@@ -157,12 +157,14 @@ struct kvm_fpu {
#define KVM_REG_MIPS_FPR (KVM_REG_MIPS_FPU | 0x0000000000000000ULL)
#define KVM_REG_MIPS_FCR (KVM_REG_MIPS_FPU | 0x0000000000000100ULL)
+#define KVM_REG_MIPS_MSACR (KVM_REG_MIPS_FPU | 0x0000000000000200ULL)
/*
* KVM_REG_MIPS_FPR - Floating point / Vector registers.
*/
#define KVM_REG_MIPS_FPR_32(n) (KVM_REG_MIPS_FPR | KVM_REG_SIZE_U32 | (n))
#define KVM_REG_MIPS_FPR_64(n) (KVM_REG_MIPS_FPR | KVM_REG_SIZE_U64 | (n))
+#define KVM_REG_MIPS_VEC_128(n) (KVM_REG_MIPS_FPR | KVM_REG_SIZE_U128 | (n))
/*
* KVM_REG_MIPS_FCR - Floating point control registers.
@@ -170,6 +172,12 @@ struct kvm_fpu {
#define KVM_REG_MIPS_FCR_IR (KVM_REG_MIPS_FCR | KVM_REG_SIZE_U32 | 0)
#define KVM_REG_MIPS_FCR_CSR (KVM_REG_MIPS_FCR | KVM_REG_SIZE_U32 | 31)
+/*
+ * KVM_REG_MIPS_MSACR - MIPS SIMD Architecture (MSA) control registers.
+ */
+#define KVM_REG_MIPS_MSA_IR (KVM_REG_MIPS_MSACR | KVM_REG_SIZE_U32 | 0)
+#define KVM_REG_MIPS_MSA_CSR (KVM_REG_MIPS_MSACR | KVM_REG_SIZE_U32 | 1)
+
/*
* KVM MIPS specific structures and definitions
diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index e02c7e5a12ff..35d3146895f1 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -531,6 +531,7 @@ static int kvm_mips_get_reg(struct kvm_vcpu *vcpu,
struct mips_fpu_struct *fpu = &vcpu->arch.fpu;
int ret;
s64 v;
+ s64 vs[2];
unsigned int idx;
switch (reg->id) {
@@ -579,6 +580,35 @@ static int kvm_mips_get_reg(struct kvm_vcpu *vcpu,
v = fpu->fcr31;
break;
+ /* MIPS SIMD Architecture (MSA) registers */
+ case KVM_REG_MIPS_VEC_128(0) ... KVM_REG_MIPS_VEC_128(31):
+ if (!kvm_mips_guest_has_msa(&vcpu->arch))
+ return -EINVAL;
+ /* Can't access MSA registers in FR=0 mode */
+ if (!(kvm_read_c0_guest_status(cop0) & ST0_FR))
+ return -EINVAL;
+ idx = reg->id - KVM_REG_MIPS_VEC_128(0);
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+ /* least significant byte first */
+ vs[0] = get_fpr64(&fpu->fpr[idx], 0);
+ vs[1] = get_fpr64(&fpu->fpr[idx], 1);
+#else
+ /* most significant byte first */
+ vs[0] = get_fpr64(&fpu->fpr[idx], 1);
+ vs[1] = get_fpr64(&fpu->fpr[idx], 0);
+#endif
+ break;
+ case KVM_REG_MIPS_MSA_IR:
+ if (!kvm_mips_guest_has_msa(&vcpu->arch))
+ return -EINVAL;
+ v = boot_cpu_data.msa_id;
+ break;
+ case KVM_REG_MIPS_MSA_CSR:
+ if (!kvm_mips_guest_has_msa(&vcpu->arch))
+ return -EINVAL;
+ v = fpu->msacsr;
+ break;
+
/* Co-processor 0 registers */
case KVM_REG_MIPS_CP0_INDEX:
v = (long)kvm_read_c0_guest_index(cop0);
@@ -664,6 +694,10 @@ static int kvm_mips_get_reg(struct kvm_vcpu *vcpu,
u32 v32 = (u32)v;
return put_user(v32, uaddr32);
+ } else if ((reg->id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U128) {
+ void __user *uaddr = (void __user *)(long)reg->addr;
+
+ return copy_to_user(uaddr, vs, 16);
} else {
return -EINVAL;
}
@@ -675,6 +709,7 @@ static int kvm_mips_set_reg(struct kvm_vcpu *vcpu,
struct mips_coproc *cop0 = vcpu->arch.cop0;
struct mips_fpu_struct *fpu = &vcpu->arch.fpu;
s64 v;
+ s64 vs[2];
unsigned int idx;
if ((reg->id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U64) {
@@ -689,6 +724,10 @@ static int kvm_mips_set_reg(struct kvm_vcpu *vcpu,
if (get_user(v32, uaddr32) != 0)
return -EFAULT;
v = (s64)v32;
+ } else if ((reg->id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U128) {
+ void __user *uaddr = (void __user *)(long)reg->addr;
+
+ return copy_from_user(vs, uaddr, 16);
} else {
return -EINVAL;
}
@@ -742,6 +781,32 @@ static int kvm_mips_set_reg(struct kvm_vcpu *vcpu,
fpu->fcr31 = v;
break;
+ /* MIPS SIMD Architecture (MSA) registers */
+ case KVM_REG_MIPS_VEC_128(0) ... KVM_REG_MIPS_VEC_128(31):
+ if (!kvm_mips_guest_has_msa(&vcpu->arch))
+ return -EINVAL;
+ idx = reg->id - KVM_REG_MIPS_VEC_128(0);
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+ /* least significant byte first */
+ set_fpr64(&fpu->fpr[idx], 0, vs[0]);
+ set_fpr64(&fpu->fpr[idx], 1, vs[1]);
+#else
+ /* most significant byte first */
+ set_fpr64(&fpu->fpr[idx], 1, vs[0]);
+ set_fpr64(&fpu->fpr[idx], 0, vs[1]);
+#endif
+ break;
+ case KVM_REG_MIPS_MSA_IR:
+ if (!kvm_mips_guest_has_msa(&vcpu->arch))
+ return -EINVAL;
+ /* Read-only */
+ break;
+ case KVM_REG_MIPS_MSA_CSR:
+ if (!kvm_mips_guest_has_msa(&vcpu->arch))
+ return -EINVAL;
+ fpu->msacsr = v;
+ break;
+
/* Co-processor 0 registers */
case KVM_REG_MIPS_CP0_INDEX:
kvm_write_c0_guest_index(cop0, v);
--
2.0.5
^ permalink raw reply related
* [PATCH v2 20/20] MIPS: KVM: Wire up MSA capability
From: James Hogan @ 2015-03-26 16:08 UTC (permalink / raw)
To: Paolo Bonzini, kvm, linux-mips
Cc: James Hogan, Ralf Baechle, Gleb Natapov, Jonathan Corbet,
linux-api, linux-doc
In-Reply-To: <1427386113-30515-1-git-send-email-james.hogan@imgtec.com>
Now that the code is in place for KVM to support MIPS SIMD Architecutre
(MSA) in MIPS guests, wire up the new KVM_CAP_MIPS_MSA capability.
For backwards compatibility, the capability must be explicitly enabled
in order to detect or make use of MSA from the guest.
The capability is not supported if the hardware supports MSA vector
partitioning, since the extra support cannot be tested yet and it
extends the state that the userland program would have to save.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Gleb Natapov <gleb@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc: linux-api@vger.kernel.org
Cc: linux-doc@vger.kernel.org
---
Changes in v2:
- Rebased on KVM queue (KVM_CAP_MIPS_MSA increased to 109 after
KVM_CAP_S390_VECTOR_REGISTERS took 107).
- Drop the MSA capability presence check from
kvm_vcpu_ioctl_enable_cap() now that it already calls
kvm_vm_ioctl_check_extension() (Paolo).
---
Documentation/virtual/kvm/api.txt | 12 ++++++++++++
arch/mips/kvm/mips.c | 18 ++++++++++++++++++
include/uapi/linux/kvm.h | 1 +
3 files changed, 31 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index e50cbb56272b..b888db12ab21 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3231,6 +3231,18 @@ done the KVM_REG_MIPS_FPR_* and KVM_REG_MIPS_FCR_* registers can be accessed
Config5.FRE bits are accessible via the KVM API and also from the guest,
depending on them being supported by the FPU.
+6.10 KVM_CAP_MIPS_MSA
+
+Architectures: mips
+Target: vcpu
+Parameters: args[0] is reserved for future use (should be 0).
+
+This capability allows the use of the MIPS SIMD Architecture (MSA) by the guest.
+It allows the Config3.MSAP bit to be set to enable the use of MSA by the guest.
+Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
+accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
+the guest.
+
7. Capabilities that can be enabled on VMs
------------------------------------------
diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index 35d3146895f1..bb68e8d520e8 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -880,6 +880,9 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
case KVM_CAP_MIPS_FPU:
vcpu->arch.fpu_enabled = true;
break;
+ case KVM_CAP_MIPS_MSA:
+ vcpu->arch.msa_enabled = true;
+ break;
default:
r = -EINVAL;
break;
@@ -1071,6 +1074,21 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_MIPS_FPU:
r = !!cpu_has_fpu;
break;
+ case KVM_CAP_MIPS_MSA:
+ /*
+ * We don't support MSA vector partitioning yet:
+ * 1) It would require explicit support which can't be tested
+ * yet due to lack of support in current hardware.
+ * 2) It extends the state that would need to be saved/restored
+ * by e.g. QEMU for migration.
+ *
+ * When vector partitioning hardware becomes available, support
+ * could be added by requiring a flag when enabling
+ * KVM_CAP_MIPS_MSA capability to indicate that userland knows
+ * to save/restore the appropriate extra state.
+ */
+ r = cpu_has_msa && !(boot_cpu_data.msa_id & MSA_IR_WRPF);
+ break;
default:
r = 0;
break;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 0670cf4337d6..2263e749910b 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -762,6 +762,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_S390_USER_SIGP 106
#define KVM_CAP_S390_VECTOR_REGISTERS 107
#define KVM_CAP_MIPS_FPU 108
+#define KVM_CAP_MIPS_MSA 109
#ifdef KVM_CAP_IRQ_ROUTING
--
2.0.5
^ permalink raw reply related
* Re: [PATCH v3 3/9] eeprom: Add a simple EEPROM framework for eeprom providers
From: Srinivas Kandagatla @ 2015-03-26 16:23 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard,
Rob Herring, Kumar Gala, Greg Kroah-Hartman,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <20150324225317.GD28997-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On 24/03/15 22:53, Mark Brown wrote:
> On Tue, Mar 24, 2015 at 10:30:08PM +0000, Srinivas Kandagatla wrote:
>
>> +static ssize_t bin_attr_eeprom_write(struct file *filp, struct kobject *kobj,
>> + struct bin_attribute *attr,
>> + char *buf, loff_t offset, size_t count)
>> +{
>> + struct device *dev = container_of(kobj, struct device, kobj);
>> + struct eeprom_device *eeprom = to_eeprom(dev);
>> + int rc;
>> +
>> + if (offset > eeprom->size)
>> + return -EINVAL;
>> +
>> + if (offset + count > eeprom->size)
>> + count = eeprom->size - offset;
>> +
>> + rc = regmap_bulk_write(eeprom->regmap, offset,
>> + buf, count/eeprom->stride);
>
> Are you sure that this and the read interface should be using the bulk
> interface and not the raw interface - do we want the byte swapping that
> the bulk interface provides?
>
You are correct, byte swapping is not really needed in this cases.
It should read/write data as it is.
I will fix it in next version.
> I'm also not entirely able to convince myself that the above error
> checks and code line up with what I'd expect the userspace ABI to be, we
> seem to be treating offset as both a byte offset into the data (which is
> what I'd expect the userspace ABI to do) and a word based index into the
> data (which is what the regmap API is doing). For example with 16 bit
> words offset 2 will start at the 5th byte of data but if userspace seeks
> to offset 5 it will get the 11th byte and onwards.
Thanks for spotting this, Yes, the offset from userspace should be
treated as byte oriented and the offset to regmap as word based index
into the data.
Yes, logic here needs a fix to handle data correctly.
>
> The stride and the word size are separate, they will frequently line up
> for memory mapped devices but typically won't for other devices. I
> think you need more data mangling to handle this robustly.
Yes, I agree I will address this too in next version.
thanks,
srini
>
--
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 v2 00/20] MIPS: KVM: Guest FPU & SIMD (MSA) support
From: Paolo Bonzini @ 2015-03-26 16:30 UTC (permalink / raw)
To: James Hogan, kvm, linux-mips
Cc: Paul Burton, Ralf Baechle, Gleb Natapov, Jonathan Corbet,
linux-api, linux-doc
In-Reply-To: <1427386113-30515-1-git-send-email-james.hogan@imgtec.com>
On 26/03/2015 17:08, James Hogan wrote:
> This patchset primarily adds guest Floating Point Unit (FPU) and MIPS
> SIMD Architecture (MSA) support to MIPS KVM, by enabling the host
> FPU/MSA while in guest mode.
>
> This patchset depends on Paul Burton's FP/MSA fixes patchset, which will
> make it into 4.0. I've only included the 3 patches (15, 19, 20) that
> have changed since v1, which can be found here:
> http://thread.gmane.org/gmane.linux.kernel.api/8984
Thanks, the fixes look good.
Paolo
^ permalink raw reply
* Re: [virtio-dev] Re: [PATCH] Add virtio gpu driver.
From: Michael S. Tsirkin @ 2015-03-26 16:47 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: virtio-dev-sDuHXQ4OtrM4h7I2RyI4rWD2FQJk+8+b, Dave Airlie,
Dave Airlie, David Airlie, Rusty Russell, open list,
open list:DRM DRIVERS, open list:VIRTIO CORE, NET...,
open list:ABI/API
In-Reply-To: <1427382436.8786.15.camel-3OfP5uLMi4C46o+2HkPkLj4oCIwMql/M@public.gmane.org>
On Thu, Mar 26, 2015 at 04:07:16PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > I don't know. This seems exactly like the kind of thing
> > we had in mind when we added the virtio pci capability.
> > For example, we have text in spec that requires drivers
> > to skip unknown capabilities.
> >
> > And yes, if bios pokes at a specific bar then we do
> > need to list this info in the virtio spec so this makes
> > it an issue that is virtio related.
>
> Hmm, virtio-vga is a two-in-one device basically. When virtio is
> enabled it behaves like virtio-gpu-pci, otherwise it behaves very
> simliar to stdvga. So you need to know nothing about virtio to handle
> the vga side, and I want keep it that way.
>
> When no vga compatibility is needed there always is the option to just
> use virtio-gpu-pci instead.
>
> > Yes, it's not about what we put there now. It's about being able
> > to move things about in the future without breaking guests.
>
> We don't have that today for stdvga, and I still fail to see what this
> buys us.
>
>
> Completely different thing crossing my mind: I think we can make
> virtio-vga fully compatible with stdvga. stdvga has two bars, memory
> (#0) and mmio (#2). We can make the mmio bar larger and place all the
> virtio regions there.
>
Full compatibility with some standard sounds like a better motivation,
yes.
>
> I think in any case I'll go split off the vga compatibility bits to a
> different patch (and possible a separate patch series).
>
> cheers,
> Gerd
Will you still need me to change core to claim specific memory only?
--
MST
^ permalink raw reply
* Re: [PATCH] mremap: add MREMAP_NOHOLE flag --resend
From: Vlastimil Babka @ 2015-03-26 17:25 UTC (permalink / raw)
To: Daniel Micay, David Rientjes
Cc: Aliaksey Kandratsenka, Andrew Morton, Shaohua Li,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, linux-api-u79uwXL29TY76Z2rM5mHXA,
Rik van Riel, Hugh Dickins, Mel Gorman, Johannes Weiner,
Michal Hocko, Andy Lutomirski,
google-perftools-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
In-Reply-To: <55137C06.9020608-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 03/26/2015 04:24 AM, Daniel Micay wrote:
> It's all well and good to say that you shouldn't do that, but it's the
> basis of the design in jemalloc and other zone-based arena allocators.
>
> There's a chosen chunk size and chunks are naturally aligned. An
> allocation is either a span of chunks (chunk-aligned) or has metadata
> stored in the chunk header. This also means chunks can be assigned to
> arenas for a high level of concurrency. Thread caching is then only
> necessary for batching operations to amortize the cost of locking rather
> than to reduce contention. Per-CPU arenas can be implemented quite well
> by using sched_getcpu() to move threads around whenever it detects that
> another thread allocated from the arena.
>
> With >= 2M chunks, madvise purging works very well at the chunk level
> but there's also fine-grained purging within chunks and it completely
> breaks down from THP page faults.
Are you sure it's due to page faults and not khugepaged + high value
(such as the default 511) of max_ptes_none? As reported here?
https://bugzilla.kernel.org/show_bug.cgi?id=93111
Once you have faulted in a THP, and then purged part of it and split it,
I don't think page faults in the purged part can lead to a new THP
collapse, only khugepaged can do that AFAIK.
And if you mmap smaller than 2M areas (i.e. your 256K chunks), that
should prevent THP page faults on the first fault within the chunk as well.
^ permalink raw reply
* [GIT PULL] kselftest fixes for 4.0-rc6
From: Shuah Khan @ 2015-03-26 18:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
open list:KERNEL SELFTEST F..., Shuah Khan
Hi Linus,
Could you please pull the following kselftest fix for 4.0-rc6.
thanks,
-- Shuah
The following changes since commit 9a0b57451ae8142c74d65bddb6d7765818babbed:
selftests/exec: Check if the syscall exists and bail if not
(2015-03-11 10:15:19 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-4.0-rc6
for you to fetch changes up to 67d8712dcc70aa16d8e14a52eb73870e3cbddfc2:
selftests: Fix build failures when invoked from kselftest target
(2015-03-19 09:54:55 -0600)
----------------------------------------------------------------
kselftest fixes for: 4.0-rc6
----------------------------------------------------------------
Shuah Khan (1):
selftests: Fix build failures when invoked from kselftest target
tools/testing/selftests/Makefile | 8 ++++++++
1 file changed, 8 insertions(+)
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ 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