The VHOST_VRING_F_LEGACY_BIG_ENDIAN flag informs the kernel that the
associated device is big endian. Of course, this only makes sense for
legacy virtio devices since modern virtio devices are always little
endian.
It will be used by the vhost memory accessors to byteswap vring data when
we have a
Hi,
This patchset allows vhost_net to be used with legacy virtio
when guest and host have a different endianness. It is based
on previous work by Cédric Le Goater:
https://www.mail-archive.com/kvm-ppc@vger.kernel.org/msg09848.html
As suggested by MST:
- the API now asks for a specific format (bi
Signed-off-by: Greg Kurz
---
drivers/vhost/vhost.h | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
Michael,
The vhost_is_little_endian() helper adds unconditionnal overhead to fixed
endian architectures: that is all architectures except arm and ppc64. This
was addr
Without this patch, packets are being silently dropped by the tap backend.
Signed-off-by: Greg Kurz
---
drivers/vhost/net.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index afa06d2..2923eee 100
Fix whitespace around while
Signed-off-by: Kevin Mulvey
---
virt/kvm/irqchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c
index 7f256f3..1d56a90 100644
--- a/virt/kvm/irqchip.c
+++ b/virt/kvm/irqchip.c
@@ -105,7 +105,7 @@ int kvm_s
Better alignment of loop using tabs rather than spaces, this
makes checkpatch.pl happier.
Signed-off-by: Kevin Mulvey
---
virt/kvm/kvm_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index a109370..36ab89d 100644
--- a/virt/kvm
On 17.02.15 15:24, Michael Mueller wrote:
> This patch implements the static part of the s390 cpu class definitions.
> It defines s390 cpu models by means of virtual cpu ids (enum) which contain
> information on the cpu generation, the machine class, the GA number and
> the machine type. The cpu
On 17.02.15 15:24, Michael Mueller wrote:
> This patch implements the static part of the s390 cpu class definitions.
> It defines s390 cpu models by means of virtual cpu ids (enum) which contain
> information on the cpu generation, the machine class, the GA number and
> the machine type. The cpu
On 17.02.15 15:24, Michael Mueller wrote:
> The patch implements routines to set and retrieve processor configuration
> data and to retrieve machine configuration data. The machine related data
> is used together with the cpu model facility lists to determine the list of
> supported cpu models of
On 17.02.15 15:24, Michael Mueller wrote:
> This patch implements the functions:
>
> - s390_get_proceccor_props()
> - s390_set_proceccor_props()
>
> They can be used to request or retrieve processor related information from an
> accelerator.
> That information comprises the cpu identifier, the
On Thu, Feb 19, 2015 at 06:57:24PM +0100, Paolo Bonzini wrote:
>
>
> On 19/02/2015 18:55, Andrew Jones wrote:
> >> > > (I don't have an exact number for how many times it went to EL1 because
> >> > > access_mair() doesn't have a trace point.)
> >> > > (I got the 62873 number by testing a 3rd ker
On 20 February 2015 at 14:29, Andrew Jones wrote:
> On Thu, Feb 19, 2015 at 06:57:24PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 19/02/2015 18:55, Andrew Jones wrote:
>> >> > > (I don't have an exact number for how many times it went to EL1
>> >> > > because
>> >> > > access_mair() doesn't have a
On Fri, 20 Feb 2015 14:54:23 +0100
Alexander Graf wrote:
> >
> > +/* machine related properties */
> > +typedef struct S390CPUMachineProps {
> > +uint16_t class; /* machine class */
> > +uint16_t ga; /* availability number of machine */
> > +uint16_t order; /* orde
On Fri, 20 Feb 2015 14:59:20 +0100
Alexander Graf wrote:
> > +typedef struct S390ProcessorProps {
> > +uint64_t cpuid;
> > +uint16_t ibc;
> > +uint8_t pad[6];
> > +uint64_t fac_list[S390_ARCH_FAC_LIST_SIZE_UINT64];
> > +} S390ProcessorProps;
> > +
> > +typedef struct S390MachineP
> Am 20.02.2015 um 16:00 schrieb Michael Mueller :
>
> On Fri, 20 Feb 2015 14:54:23 +0100
> Alexander Graf wrote:
>
>>>
>>> +/* machine related properties */
>>> +typedef struct S390CPUMachineProps {
>>> +uint16_t class; /* machine class */
>>> +uint16_t ga; /* availabil
On Fri, 20 Feb 2015 15:03:30 +0100
Alexander Graf wrote:
> >
> > - s390_get_proceccor_props()
> > - s390_set_proceccor_props()
> >
> > They can be used to request or retrieve processor related information from
> > an accelerator.
> > That information comprises the cpu identifier, the ICB value
On Fri, Feb 20, 2015 at 02:37:25PM +, Ard Biesheuvel wrote:
> On 20 February 2015 at 14:29, Andrew Jones wrote:
> > So looks like the 3 orders of magnitude greater number of traps
> > (only to el2) don't impact kernel compiles.
> >
>
> OK, good! That was what I was hoping for, obviously.
>
>
On Fri, 20 Feb 2015 14:55:32 +0100
Alexander Graf wrote:
> > /**
> > * S390CPUClass:
> > * @parent_realize: The parent class' realize handler.
> > @@ -52,6 +69,11 @@ typedef struct S390CPUClass {
> > void (*load_normal)(CPUState *cpu);
> > void (*cpu_reset)(CPUState *cpu);
> >
Am 20.02.2015 um 16:32 schrieb Michael Mueller:
> On Fri, 20 Feb 2015 15:03:30 +0100
> Alexander Graf wrote:
>
>>>
>>> - s390_get_proceccor_props()
>>> - s390_set_proceccor_props()
>>>
>>> They can be used to request or retrieve processor related information from
>>> an accelerator.
>>> That inf
On Fri, 20 Feb 2015 16:22:20 +0100
Alexander Graf wrote:
> >>
> >> Just make this uint64_t fac_list[2]. That way we don't have to track any
> >> messy allocations.
> >
> > It will be something like "uint64_t
> > fac_list[S390_CPU_FAC_LIST_SIZE_UINT64]" and in total 2KB
> > not just 16 bytes
On 02/17/2015 06:24 AM, Michael Mueller wrote:
> +/**
> + * s390_test_facility - test if given facility bit is set facility list
> + * of given cpu class
> + * @class: address of cpu class to test
> + * @nr: bit number to test
> + *
> + * Returns: true in case it is set
> + *
On Fri, 20 Feb 2015 16:41:49 +0100
Andreas Färber wrote:
> Can't you just implement the class-level name-to-ObjectClass callback
> that other CPUs have grown for the above use case?
If it fulfills the requirements sure. Please point me to an example, sounds that
s390_select_cpu_model() is doing
On Fri, 20 Feb 2015 16:41:49 +0100
Andreas Färber wrote:
> Also a general comment: cpu-model/ is not an existing directory nor one
> you add, so please use "target-s390x: Add foo to S390CPU" or so.
I will address this with v3, thanks a lot for the hint, I never saw this as
directories though...
On Fri, 20 Feb 2015 08:02:42 -0800
Richard Henderson wrote:
> > +/**
> > + * s390_test_facility - test if given facility bit is set facility list
> > + * of given cpu class
> > + * @class: address of cpu class to test
> > + * @nr: bit number to test
> > + *
> > + * Returns: t
2015-02-19 23:28+0100, Kashyap Chamarthy:
> On Thu, Feb 19, 2015 at 10:10:11PM +0100, Kashyap Chamarthy wrote:
> > On Thu, Feb 19, 2015 at 05:02:22PM +0100, Radim Krčmář wrote:
>
> [. . .]
>
> > > Can you try if the following patch works?
> >
> > Sure, will test a Kernel built with the below pat
Hi Linus,
The following changes since commit e36f014edff70fc02b3d3d79cead1d58f289332e:
Linux 3.19-rc7 (2015-02-01 20:07:21 -0800)
are available in the git repository at:
git://github.com/awilliam/linux-vfio.git tags/vfio-v3.20-rc1
for you to fetch changes up to 6140a8f5623820cec7f56c63444b
On Fri, 20 Feb 2015 17:12:49 +0100
Michael Mueller wrote:
> Good spot, it's not being used yet. It's planned to be used with a patch that
> implements zPCI
> related instructions on QEMU side. Maybe you have seen the discussion from
> Frank Blaschka in
> this e-mail list in regard to that.
I w
Am 20.02.2015 um 17:04 schrieb Michael Mueller:
> On Fri, 20 Feb 2015 16:41:49 +0100
> Andreas Färber wrote:
>
>> Can't you just implement the class-level name-to-ObjectClass callback
>> that other CPUs have grown for the above use case?
>
> If it fulfills the requirements sure. Please point me
Am 20.02.2015 um 17:12 schrieb Michael Mueller:
> On Fri, 20 Feb 2015 08:02:42 -0800
> Richard Henderson wrote:
>
>>> +/**
>>> + * s390_test_facility - test if given facility bit is set facility list
>>> + * of given cpu class
>>> + * @class: address of cpu class to test
>>>
On Fri, 20 Feb 2015 17:28:14 +0100
Andreas Färber wrote:
Andreas,
> Sorry for my ignorance, but what is proc actually needed for? For
> initializing the class, there's .class_init (and cc->fac_list apparently
> is initialized here). If you need to pass info to KVM, you can do so in
yes, it is c
On Fri, 20 Feb 2015 17:34:28 +0100
Andreas Färber wrote:
> Please note that QEMU uses gtk-doc style, where the description goes
> between arguments and Returns:, and the function name gets a ':'.
> There's also fancy syntax like #CPUClass, %true, etc.
On my TODOs...
Thanks,
Michael
--
To unsub
On 20.02.15 16:49, Michael Mueller wrote:
> On Fri, 20 Feb 2015 16:22:20 +0100
> Alexander Graf wrote:
>
Just make this uint64_t fac_list[2]. That way we don't have to track any
messy allocations.
>>>
>>> It will be something like "uint64_t
>>> fac_list[S390_CPU_FAC_LIST_SIZE_
On 20.02.15 16:18, Michael Mueller wrote:
> On Fri, 20 Feb 2015 14:59:20 +0100
> Alexander Graf wrote:
>
>>> +typedef struct S390ProcessorProps {
>>> +uint64_t cpuid;
>>> +uint16_t ibc;
>>> +uint8_t pad[6];
>>> +uint64_t fac_list[S390_ARCH_FAC_LIST_SIZE_UINT64];
>>> +} S390Proc
On 20.02.15 16:32, Michael Mueller wrote:
> On Fri, 20 Feb 2015 15:03:30 +0100
> Alexander Graf wrote:
>
>>>
>>> - s390_get_proceccor_props()
>>> - s390_set_proceccor_props()
>>>
>>> They can be used to request or retrieve processor related information from
>>> an accelerator.
>>> That informa
KVM folks, Linus,
my second son should be getting out of his current cozy location very
soon, after which I'll be working part time for about a month.
During this period, I will not have enough time to devote to KVM
maintainership, and Marcelo will therefore take care of the kernel KVM
tree from
On Fri, 20 Feb 2015 17:57:52 +0100
Alexander Graf wrote:
> Because all CPUs we have in our list only expose 128 bits?
Here a STFLE result on a EC12 GA2, already more than 128 bits... Is that model
on the list?
[mimu@p57lp59 s390xfac]$ ./s390xfac -b
fac[0] = 0xfbfbfcfff840
fac[1] = 0xffde00
> Am 20.02.2015 um 18:37 schrieb Michael Mueller :
>
> On Fri, 20 Feb 2015 17:57:52 +0100
> Alexander Graf wrote:
>
>> Because all CPUs we have in our list only expose 128 bits?
>
> Here a STFLE result on a EC12 GA2, already more than 128 bits... Is that
> model on the list?
If that model
On 02/17/2015 06:24 AM, Michael Mueller wrote:
> +static inline uint64_t big_endian_bit(unsigned long nr)
> +{
> +return 1ul << (BITS_PER_LONG - (nr % BITS_PER_LONG));
> +};
This is buggy. NR=0 should map to 63, not 64.
> +return !!(*ptr & big_endian_bit(nr));
Personally I dislike !! as
On Fri, 20 Feb 2015 17:59:14 +0100
Alexander Graf wrote:
> But please give a nutshell explanation on what exactly you're patching
> at all here.
Please don't ask in riddles... :-)
S390ProcessorProps are attributes that represent cpu model related properties
of the processor.
typedef struct S
KVM has nice wrappers to access the register values, clean up a few places
that should use them but currently do not.
Signed-off-by:David Kaplan
Signed-off-by:Joel Schopp
---
arch/x86/kvm/svm.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/x86/k
On Fri, 20 Feb 2015 10:11:55 -0800
Richard Henderson wrote:
> > +static inline uint64_t big_endian_bit(unsigned long nr)
> > +{
> > +return 1ul << (BITS_PER_LONG - (nr % BITS_PER_LONG));
> > +};
>
> This is buggy. NR=0 should map to 63, not 64.
I'm sure I was asked to replace my constant
> Am 20.02.2015 um 19:59 schrieb Michael Mueller :
>
> On Fri, 20 Feb 2015 10:11:55 -0800
> Richard Henderson wrote:
>
>>> +static inline uint64_t big_endian_bit(unsigned long nr)
>>> +{
>>> +return 1ul << (BITS_PER_LONG - (nr % BITS_PER_LONG));
>>> +};
>>
>> This is buggy. NR=0 shoul
On Fri, 20 Feb 2015 18:00:19 +0100
Alexander Graf wrote:
> > So above s390_set/get_processor_props() the code is accelerator
> > independent.
>
> Any particular reason you can't do it like PPC?
That seems to be a short question... and when I started one year ago, I
oriented myself on
the PP
On Fri, 20 Feb 2015 20:21:45 +0100
Alexander Graf wrote:
>
>
>
> > Am 20.02.2015 um 19:59 schrieb Michael Mueller :
> >
> > On Fri, 20 Feb 2015 10:11:55 -0800
> > Richard Henderson wrote:
> >
> >>> +static inline uint64_t big_endian_bit(unsigned long nr)
> >>> +{
> >>> +return 1ul << (B
On Fri, 20 Feb 2015 18:50:20 +0100
Alexander Graf wrote:
>
>
>
> > Am 20.02.2015 um 18:37 schrieb Michael Mueller :
> >
> > On Fri, 20 Feb 2015 17:57:52 +0100
> > Alexander Graf wrote:
> >
> >> Because all CPUs we have in our list only expose 128 bits?
> >
> > Here a STFLE result on a EC12
On Fri, Feb 20, 2015 at 05:14:15PM +0100, Radim Krčmář wrote:
> 2015-02-19 23:28+0100, Kashyap Chamarthy:
> > On Thu, Feb 19, 2015 at 10:10:11PM +0100, Kashyap Chamarthy wrote:
> > > On Thu, Feb 19, 2015 at 05:02:22PM +0100, Radim Krčmář wrote:
[. . .]
> > Then, I did another test:
> >
> > - R
On 20.02.15 20:43, Michael Mueller wrote:
> On Fri, 20 Feb 2015 18:50:20 +0100
> Alexander Graf wrote:
>
>>
>>
>>
>>> Am 20.02.2015 um 18:37 schrieb Michael Mueller :
>>>
>>> On Fri, 20 Feb 2015 17:57:52 +0100
>>> Alexander Graf wrote:
>>>
Because all CPUs we have in our list only expose
On Fri, Feb 20, 2015 at 12:39:40PM -0600, Joel Schopp wrote:
> KVM has nice wrappers to access the register values, clean up a few places
> that should use them but currently do not.
>
> Signed-off-by:David Kaplan
> Signed-off-by:Joel Schopp
This SOB chain looks strange. If David is the author,
On 02/20/2015 02:54 PM, Borislav Petkov wrote:
> On Fri, Feb 20, 2015 at 12:39:40PM -0600, Joel Schopp wrote:
>> KVM has nice wrappers to access the register values, clean up a few places
>> that should use them but currently do not.
>>
>> Signed-off-by:David Kaplan
>> Signed-off-by:Joel Schopp
From: David Kaplan
KVM has nice wrappers to access the register values, clean up a few places
that should use them but currently do not.
Signed-off-by: David Kaplan
[forward port and testing]
Signed-off-by: Joel Schopp
---
arch/x86/kvm/svm.c | 19 +--
1 file changed, 9 inser
From: David Kaplan
Reduce the number of exits by avoiding exiting when the guest writes TS or MP
bits of CR0. INTERCEPT_CR0_WRITE intercepts all writes to CR0 including TS and
MP bits. It intercepts these even if INTERCEPT_SELECTIVE_CR0 is set. What we
should be doing is setting INTERCEPT_SELEC
On Fri, Feb 20, 2015 at 04:02:10PM -0600, Joel Schopp wrote:
> From: David Kaplan
>
> KVM has nice wrappers to access the register values, clean up a few places
> that should use them but currently do not.
>
> Signed-off-by: David Kaplan
> [forward port and testing]
> Signed-off-by: Joel Schopp
52 matches
Mail list logo
