2015-06-10 11:31+0100, Marc Zyngier:
>On 10/06/15 10:54, Igor Mammedov wrote:
>> On Tue, 09 Jun 2015 15:35:21 +0100
>> Marc Zyngier wrote:
>>> Indeed. I also missed the step that says "kernel is able to convert
>>> arbitrary MPIDR to vcpu_id in an efficient manner...". GICv3 is
>>> definitely goin
KVM_CAP_INTERNAL_ERROR_DATA condition on printf.
(partially improved by bb44e0d12df70 and ba4047cf848a3 in the past)
Signed-off-by: Radim Krčmář
---
kvm-all.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 0bfb060..0a91d8e 100644
--- a/kvm-all.c
+++ b/kvm
Automatic shrinking of vram_size leads to a segfault, because other
variables depend on being smaller and don't get shrinked.
Implications of shrinking would make the code needlessly complicated;
assert instead.
Signed-off-by: Radim Krčmář
---
hw/display/vga.c | 10 +++---
1 file ch
The solution is not perfect, but won't let us do the same error again
and has no overhead.
Signed-off-by: Radim Krčmář
---
hw/display/qxl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index 61df47726481..d5e85d033080 100644
--- a/hw/display/
with them everywhere)
(Disclaimer: not on my TODO.)
Radim Krčmář (2):
vga: abort instead of shrinking memory
qxl: surface0 and ram_header should fit into vram
hw/display/qxl.c | 2 ++
hw/display/vga.c | 10 +++---
2 files changed, 5 insertions(+), 7 deletions(-)
--
2.3.0
2015-02-17 09:00+0100, Gerd Hoffmann:
> On Mo, 2015-02-16 at 22:23 +0100, Radim Krčmář wrote:
> > Automatic shrinking of vram_size leads to a segfault, because other
> > variables depend on being smaller and don't get shrinked.
>
> --verbose please. Which other varia
2015-02-17 09:02+0100, Gerd Hoffmann:
> On Mo, 2015-02-16 at 22:23 +0100, Radim Krčmář wrote:
> > The solution is not perfect, but won't let us do the same error again
> > and has no overhead.
>
> How do you get qemu into a configuration where this isn't true?
2015-02-17 11:37+0100, Gerd Hoffmann:
> On Di, 2015-02-17 at 11:29 +0100, Radim Krčmář wrote:
> > 2015-02-17 09:00+0100, Gerd Hoffmann:
> > > On Mo, 2015-02-16 at 22:23 +0100, Radim Krčmář wrote:
> > > > Automatic shrinking of vram_size leads to a segfault, because
2015-02-17 11:51+0100, Gerd Hoffmann:
> Hi,
>
> > > Which command line triggers it?
> >
> > The important subset is:
> > -vga qxl -global qxl-vga.vgamem_mb=512
>
> Ah, so the problem is only one place enforces a upper limit, so we can
> get an invalid configuration with large values.
(I thi
rt if it happens again.
We have to bump the vga memory limit too, because 256 MiB wouldn't have
allowed 8k (it requires more than 128 MiB).
1024 MiB doesn't work, but 512 MiB seems fine.
Proposed-by: Gerd Hoffmann
Signed-off-by: Radim Krčmář
---
v2: changed numbers in Gerd's solution
Make the code a bit more obvious.
We don't have min/max, so a general helper for clamp probably isn't
acceptable either.
Signed-off-by: Radim Krčmář
---
v2: kept rounding and clamping (was [v1 1/2])
hw/display/vga.c | 22 +++---
1 file changed, 15 insertions(+), 7
We already have pow2floor, mirror it and use instead of a function with
similar results (same in used domain), to clarify our intent.
Signed-off-by: Radim Krčmář
---
v2: new
hw/display/qxl.c | 23 +--
include/qemu-common.h | 3 +++
util/cutils.c | 14
t one nice patch
- removed assert and kept rounding+lamping in [4/4]
Radim Krčmář (4):
qxl: document minimal video memory for new modes
spice: fix invalid memory access to vga.vram
qxl: refactor rounding up to a nearest power of 2
vga: refactor vram_size clamping and rounding
hw/display/
The alternative to removing existing comments.
Signed-off-by: Radim Krčmář
---
v2: new
hw/display/qxl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index 61df47726481..6e9079783e27 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -120,9
other register, but it would most likely only add
more useless code, because normal operations shouldn't behave like that
anyway. (An OS that deliberately keeps bits in ICR to notify itself
that there are more packets, or for more creative reasons, is nothing we
should care about.)
Sig
2015-02-19 20:24+0100, Radim Krčmář:
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> @@ -138,6 +138,10 @@ typedef struct E1000State_st {
> +#define E1000_WIN8_WORKAROUND_ICR E1000_ICR_RXT0
> +#define E1000_WIN8_WORKAROUND_DELAY_US 10
> +bool win8_workaround_needed;
>
GCC is more strict now.
Radim Krčmář (2):
fix GCC 5.0.0 logical-not-parentheses warnings
milkymist-pfpu: fix GCC 5.0.0 aggressive-loop-optimizations warning
hw/misc/milkymist-pfpu.c | 18 --
hw/net/virtio-net.c | 2 +-
kvm-all.c| 2 +-
qemu-img.c
ere
uint32_t insn = s->microcode[pc];
^
Signed-off-by: Radim Krčmář
---
hw/misc/milkymist-pfpu.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/hw/misc/milkymist-pfpu.c b/hw/misc/milkymist-pfpu.c
index 609f33f9cd14..133f5b8c5153 100644
--- a/h
& ERR_STAT));
even thought the second operand is int (and first hunk of this patch has
a very similar case), maybe GCC developers still have a little faith in
C programmers.
Signed-off-by: Radim Krčmář
---
hw/net/virtio-net.c | 2 +-
kvm-all.c | 2 +-
qemu-img.c | 3 ++-
3 f
2015-02-20 15:18+0100, Radim Krčmář:
> diff --git a/hw/misc/milkymist-pfpu.c b/hw/misc/milkymist-pfpu.c
> @@ -164,6 +164,13 @@ output_queue_advance(MilkymistPFPUState *s)
> static int pfpu_decode_insn(MilkymistPFPUState *s)
> {
> uint32_t pc = s->regs[R_PC];
2015-02-20 23:40+0900, Peter Maydell:
> On 20 February 2015 at 23:18, Radim Krčmář wrote:
> > man gcc:
> > Warn if in a loop with constant number of iterations the compiler
> > detects undefined behavior in some statement during one or more of
> > the iterations.
2015-02-20 15:38+0100, Paolo Bonzini:
> On 20/02/2015 15:18, Radim Krčmář wrote:
> > -if (!!n->vhost_started ==
> > +if ((!!n->vhost_started) ==
> > (virtio_net_started(n, status) && !nc->peer->link_down)) {
>
> Does it still bre
2015-02-20 15:55+0100, Paolo Bonzini:
>
>
> On 20/02/2015 15:52, Michael Walle wrote:
> >>>
> >>> -i = 0;
> >>> -while (pfpu_decode_insn(s)) {
> >>> -/* decode at most MICROCODE_WORDS instructions */
> >>> -if (i++ >= MICROCODE_WORDS) {
> >>
& ERR_STAT));
even thought the second operand is int (and first hunk of this patch has
a very similar case), maybe GCC developers still have a little faith in
C programmers.
Signed-off-by: Radim Krčmář
---
v2: swapped lines in hunk 1 to to avoid parentheses [Paolo]
hw/net/virtio-net.c | 4
_WORDS) {
^
hw/misc/milkymist-pfpu.c:167:14: note: possible undefined statement is here
uint32_t insn = s->microcode[pc];
^
The code can still access out of bounds, because it presumes that PC register
always begins at 0, and we allow writing to it.
Signed-off-by: Rad
Future patches should address the out-of-bounds access that is left by
using proposed solution for [2/2].
Radim Krčmář (2):
fix GCC 5.0.0 logical-not-parentheses warnings
milkymist-pfpu: fix GCC 5.0.0 aggressive-loop-optimizations warning
hw/misc/milkymist-pfpu.c | 2 +-
hw/net/virtio-net.c
Cc: qemu-triv...@nongnu.org
2015-02-23 10:45+, Stefan Hajnoczi:
> On Thu, Feb 19, 2015 at 09:37:46PM +0100, Radim Krčmář wrote:
> > 2015-02-19 20:24+0100, Radim Krčmář:
> > > diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> > > @@ -138,6 +138,10 @@ typedef struct E1000State_st {
> > >
2015-02-23 14:39+, Stefan Hajnoczi:
> Since the typo breaks compilation, it shows that the patch was not
> tested. That makes me nervous.
(It was based on a tested RHEL7 patch. Upstream allowed for better
code, so I didn't want to push the ugly, yet working, version.)
Honestly, I was hopin
2015-03-25 20:05-0400, Kevin O'Connor:
> On Thu, Mar 26, 2015 at 02:35:58AM +0300, Andrey Korolyov wrote:
> > Thanks, strangely the reboot is always failing now and always reaching
> > seabios greeting. May be prints straightened up a race (e.g. it is not
> > int19 problem really).
> >
> > object
2015-03-26 19:48+0300, Andrey Korolyov:
> I`ll post a sample event
> capture with and without Radim`s proposed patch maybe today or
> tomorrow.
Thanks.
The patch doesn't change runtime behavior, it just adds another data
field to the er
2015-03-26 12:36-0400, Kevin O'Connor:
> On Thu, Mar 26, 2015 at 04:58:07PM +0100, Radim Krčmář wrote:
> > Notice the 0xef. My best hypothesis so far is that we fail at resetting
> > devices, and 0xef is LOCAL_TIMER_VECTOR from Linux before we rebooted.
> > (The bug
2015-03-26 20:08+0300, Andrey Korolyov:
> KVM internal error. Suberror: 2
> extra data[0]: 80ef
> extra data[1]: 8b0d
Btw. does this part ever change?
I see that first report had:
KVM internal error. Suberror: 2
extra data[0]: 80d1
extra data[1]: 8b0d
Was that a Windows gu
2015-03-26 21:24+0300, Andrey Korolyov:
> On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář wrote:
> > 2015-03-26 20:08+0300, Andrey Korolyov:
> >> KVM internal error. Suberror: 2
> >> extra data[0]: 80ef
> >> extra data[1]: 8b0d
> >
> > Btw
2015-03-27 13:16+0300, Andrey Korolyov:
> On Fri, Mar 27, 2015 at 12:03 AM, Bandan Das wrote:
> > Radim Krčmář writes:
> >> I second Bandan -- checking that it reproduces on other machine would be
> >> great for sanity :) (Although a bug in our APICv is far more lik
2015-03-27 14:54+0300, Andrey Korolyov:
> Trace with new bits:
Thanks.
> KVM internal error. Suberror: 2
> extra data[0]: 80ef
> extra data[1]: 8b0d
> extra data[2]: 77b
The #GP code looks formatted as documented under INT in SDM,
(vector << 3) | 2 | ext
where 'ext' stands for 'externa
2015-03-31 13:26+0800, Jason Wang:
> On 02/20/2015 03:24 AM, Radim Krčmář wrote:
> > Window 8.0 driver has a particular behavior for a small time frame after
> > it enables rx interrupts: the interrupt handler never clears
> > E1000_ICR_RXT0. The handler does thi
2015-03-30 22:32+0300, Andrey Korolyov:
> On Mon, Mar 30, 2015 at 9:56 PM, Radim Krčmář wrote:
> > 2015-03-27 13:16+0300, Andrey Korolyov:
> >> On Fri, Mar 27, 2015 at 12:03 AM, Bandan Das wrote:
> >> > Radim Krčmář writes:
> >> >> I second Bandan --
2015-03-31 17:56+0300, Andrey Korolyov:
> > Chasing the culprit this way could take a long time, so a new tracepoint
> > that shows if 0xef is set on entry would let us guess the bug faster ...
> >
> > Please provide a failing trace with the following patch:
>
> Thanks, please see below:
>
> http:
2015-03-31 21:23+0300, Andrey Korolyov:
> On Tue, Mar 31, 2015 at 9:04 PM, Bandan Das wrote:
> > Bandan Das writes:
> >> Andrey Korolyov writes:
> >> ...
> >>> http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz
> >>>
> >>> Something a bit more interesting, but the
The APIC ID topology is made of three elements:
smt, core and pkg id; bit width of first two is determined by the
actual number of hyperthreads/cores and pkg gets the rest.
Basic xAPIC unit tests are included.
Signed-off-by: Radim Krčmář
---
target-i386/topology.h | 13 +
tests
for better wording ...
(The main problem of this series is benefit/code ratio.)
Radim Krčmář (3):
target-i386: add apicid_pkg_width to topology.h
target-i386: introduce x86_cpu_nr_apic_ids
pc: improve error message with impossible max_cpus
hw/i386/pc.c | 12 +++-
target-
The number of available APIC IDs depends on chosen topology, because
core/smt choices different from a power of two waste some IDs.
Signed-off-by: Radim Krčmář
---
target-i386/cpu.c | 16
target-i386/cpu.h | 1 +
2 files changed, 17 insertions(+)
diff --git a/target-i386
are likely interested about the maximal maxcpus, so use that instead.
Signed-off-by: Radim Krčmář
---
hw/i386/pc.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 61aba9f..557b3cc 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -
2014-12-10 18:55+0100, Paolo Bonzini:
> Well, my preferred choice would be automatic adjustment with a module
> parameter. If we need manual tuning, per-CPU would be my choice, but
> automatic is nicer anyway. :)
I agree with Paolo, and think it would be better not to touch QEMU ...
it makes litt
2015-04-06 17:45-0600, James Sullivan:
> Currently, apic_get_arb_pri() is unimplemented and returns 0.
>
> Implemented apic_get_arb_pri() and added two helper functions
> apic_compare_prio() and apic_lowest_prio() to be used for LAPIC
> arbitration.
>
> Signed-off-by: James Sullivan
> ---
> +sta
2015-04-06 17:45-0600, James Sullivan:
> Added argument to apic_get_delivery_bitmask() for msi_redir_hint,
> and changed calls to the function accordingly (using 0 as a default
> value for non-MSI interrupts).
>
> Modified the implementation of apic_get_delivery_bitmask() to account
> for the RH b
2015-04-23 12:34-0600, James Sullivan:
> On 04/23/2015 07:49 AM, Radim Krčmář wrote:
>> 2015-04-06 17:45-0600, James Sullivan:
>>> Currently, apic_get_arb_pri() is unimplemented and returns 0.
>>>
>>> Implemented apic_get_arb_pri() and added two helper f
2015-04-23 13:08-0600, James Sullivan:
> On 04/23/2015 08:14 AM, Radim Krčmář wrote:
>> 2015-04-06 17:45-0600, James Sullivan:
>>> diff --git a/hw/intc/apic.c b/hw/intc/apic.c
>>> @@ -519,23 +521,27 @@ static void apic_get_delivery_bitmask(uint32_t
>>> *
;& 0xb' on this result is completely beyond me.)
Also, the device used to be PEVT. (PEVT as in "panic event"?)
Signed-off-by: Radim Krčmář
---
hw/i386/acpi-build.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/ac
2015-05-29 10:51+0200, Igor Mammedov:
> On Wed, 27 May 2015 18:29:17 +0200
> Radim Krčmář wrote:
> > In the old times, we always had pvpanic in ACPI and a _STA function told
> > the guest not to use it. Now, we only include pvpanic in ACPI if it is
> > enabled, so the
(Zero) }
Else {
Return (0x0F) }}
Igor pointed out that we don't need to use a method to return a constant
and that 0xB (don't show in UI) is the common definition now.
Also, the device used to be PEVT. (PEVT as in "panic event"?)
Signed-off-by: Radim Krčmá
2015-03-04 17:36+0300, Michael Tokarev:
> 20.02.2015 19:06, Radim Krčmář wrote:
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > -if (!!n->vhost_started ==
> > -(virtio_net_started(n, status) && !nc->peer->link_down)) {
> > +
2015-03-05 12:57+0800, Dongsheng Song:
> On Wed, Mar 4, 2015 at 10:30 PM, Gerd Hoffmann wrote:
> > +/* round up to the nearest power of 2 (0 if overflow) */
> > +uint64_t pow2ceil(uint64_t value)
> > +{
> > +uint8_t nlz = clz64(value);
> > +
> > +if (is_power_of_2(value)) {
> > +re
2015-03-05 10:52+0100, Markus Armbruster:
> Gerd Hoffmann writes:
>
> > From: Radim Krčmář
> >
> > We already have pow2floor, mirror it and use instead of a function with
> > similar results (same in used domain), to clarify our intent.
> >
> > Sign
100 (NMI), and 101 (INIT) as indicated in this section,
> must not be used and is not supported.
>
> In theory the PIIX4 could deliver such messages, but perhaps we could
> disable them in the KVM IOAPIC. If we do this, there is no need for a
> change to struct kvm_vcpu_events,
k we only
need to use one for MSI region and add attributes to direct writers
(like HPET and IOAPIC, because normal PCI devices should be passing
correct attributes).
> ...
>>> FWIW, Radim was thinking of interrupt remapping in the kvm-ioapic, which
>>> we have decided to set
ink, how could we benefit from each other?
>
> - Radim was telling me to look on this as well. How do your efforts
> correlate?
I wasn't aware of Peter's project ...
Peter, my goal is to support x2APIC to get closer to supporting more
than 255 VCPUs. Please Cc me in future discussions/patches!
Thanks.
2015-10-22 18:14+0200, Paolo Bonzini:
> On 22/10/2015 18:02, Eric Blake wrote:
>> I see a bug in there:
>
> Of course. You shouldn't have told me what the bug was, I deserved
> to look for it myself. :)
It rather seems that you don't want spoilers, :)
I see two bugs now.
> bool memeqzero4_paol
Previous patch changed xlevel and missed the compatibility code.
Fixes: 3046bb5debc8 ("target-i386: emulate CPUID level of real hardware")
Signed-off-by: Radim Krčmář
---
include/hw/i386/pc.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/hw/i386/pc.h b/include/hw
2015-08-18 16:54+0200, Peter Lieven:
> After some experiments I was able to find out the bad commit that introduced
> the regression:
>
> commit f30ebc312ca9def25650b4e1d01cdb425c310dca
> Author: Radim Krčmář
> Date: Thu Oct 30 15:06:47 2014 +0100
>
> It seems that
2015-07-06 10:39-0300, Eduardo Habkost:
> On Sun, Jul 05, 2015 at 07:33:31PM +0100, Peter Maydell wrote:
> > On 3 July 2015 at 21:47, Eduardo Habkost wrote:
> > > The following changes since commit
> > > 35360642d043c2a5366e8a04a10e5545e7353bd5:
> > >
> > > Merge remote-tracking branch
> > > '
used http://instlatx64.atw.hu/ as a source of CPUID and checked that
it matches Penryn Xeon X5472, Westmere Xeon W3520, SandyBridge i5-2540M,
and Haswell i5-4670T.
kvm64 and qemu64 were bumped to 0xD to allow all available features for
them (and to avoid the same Windows bug).
Signed-off-by:
efinition and #if typedef
it for old versions.
Signed-off-by: Radim Krčmář
---
I don't know if we want to kill the #if compatibility after a while
(so QEMU doesn't become glibc-like) -- I could split this patch into
two, where the first one would just be reverted.
configure
2015-07-10 13:56+0100, Peter Maydell:
> On 10 July 2015 at 13:33, Radim Krčmář wrote:
>> @@ -83,8 +87,8 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm
>> alg,
>> -ctx->alg_encrypt = (nettle_crypt_func *)des_encrypt;
>> -ctx->
2015-07-10 14:38+0100, Peter Maydell:
> On 10 July 2015 at 14:31, Radim Krčmář wrote:
>> 2015-07-10 13:56+0100, Peter Maydell:
>>> On 10 July 2015 at 13:33, Radim Krčmář wrote:
>>>> @@ -83,8 +87,8 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorith
[1/3] fixes a build problem with new nettle libraries.
Peter Maydell found a potential undefined behavior with some architectures that
is fixed in [2/3]. (I haven't checked if QEMU runs on one.)
[3/3] refactors [2/3]; feel free to squish or drop it.
Radim Krčmář (3):
crypto: fix build
efinition and #if typedef
it for old versions.
Signed-off-by: Radim Krčmář
---
configure | 4 +++-
crypto/cipher-nettle.c | 16 ++--
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/configure b/configure
index 33b945530e64..cc0338ddbd14 100755
--- a/configur
It's horrible both ways and I prefer this one.
Signed-off-by: Radim Krčmář
---
crypto/cipher-nettle.c | 47 +--
1 file changed, 17 insertions(+), 30 deletions(-)
diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
index 61f1cd3
truct XXX *' might require
computation, which won't be done if we drop argument's true type, and
pointers can have different sizes so passing arguments on stack would
bug.)
Having two different prototypes based on nettle version doesn't make
this solution any nicer.
Reported-b
2015-07-10 14:56+0100, Peter Maydell:
> On 10 July 2015 at 14:38, Peter Maydell wrote:
>> On 10 July 2015 at 14:31, Radim Krčmář wrote:
>>> We pass 'ctx' as a 'void *' in the code, but these functions accept
>>> specialized structures
2015-07-10 19:18+0200, Radim Krčmář:
> diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
> +void aes_encrypt_wrapper(cipher_ctx_t ctx, cipher_length_t length,
> + uint8_t *dst, const uint8_t *src)
Wrappers should be static (rushed posting). I'll
fined behavior[2-3/3]
Radim Krčmář (3):
crypto: fix build with nettle >= 3.0.0
crypto: avoid undefined behavior in nettle calls
crypto: use CPP for wrapper definitions in nettle
configure | 4 +++-
crypto/cipher-nettle.c | 38 --
2 files
It's horrible both ways and I prefer this one.
Signed-off-by: Radim Krčmář
---
v3: make wrappers 'static'
v2: new
crypto/cipher-nettle.c | 47 +--
1 file changed, 17 insertions(+), 30 deletions(-)
diff --git a/crypto/cipher-ne
efinition and #if typedef
it for old versions.
Signed-off-by: Radim Krčmář
---
v3: no change
v2: fix typo in crypto
configure | 4 +++-
crypto/cipher-nettle.c | 16 ++--
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/configure b/configure
index 33b
truct XXX *' might require
computation, which won't be done if we drop argument's true type and
pointers can have different sizes so passing arguments on stack would
bug.)
Having two different prototypes based on nettle version doesn't make
this solution any nicer.
Repor
The first patch uses CPUID levels from the internet, which has a nice
side effect of making W10 insider preview bootable.
The second patch is a traditional buggy bug fix.
Radim Krčmář (2):
target-i386: emulate CPUID level of real hardware
target-i386: automatically raise cpuid level to 0xd
;
and amend xlevel while at it.
I have used http://instlatx64.atw.hu/ as a source of CPUID and checked
that it matches Penryn Xeon X5472, Westmere Xeon W3520, SandyBridge
i5-2540M, and Haswell i5-4670T.
kvm64 and qemu64 were bumped to 0xD to avoid similar problems.
Signed-off-by: Radim Krčmář
---
t
We already bump to level 7 if features there are requested, so do the
same for 0xD.
Signed-off-by: Radim Krčmář
---
If we want this behavior, we should not do it by writing a case for
every level.
target-i386/cpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/target-i386/cpu.c b
2015-06-18 17:29+0200, Paolo Bonzini:
> On 18/06/2015 17:24, Radim Krčmář wrote:
> > W10 insider has a bug where it ignores CPUID level and interprets
> > CPUID.(EAX=07H, ECX=0H) incorrectly, because CPUID in fact returned
> > CPUID.(EAX=04H, ECX=0H); this resulted in exe
2015-06-18 12:50-0300, Eduardo Habkost:
> On Thu, Jun 18, 2015 at 05:24:24PM +0200, Radim Krčmář wrote:
> > We already bump to level 7 if features there are requested, so do the
> > same for 0xD.
> >
> > Signed-off-by: Radim Krčmář
>
> This breaks guest ABI and
2015-06-19 11:47+0200, Radim Krčmář:
> 2015-06-18 12:50-0300, Eduardo Habkost:
> > I have considered introducing "min-[x]level" and "max-{x]level"
> > properties to control automatic increasing of level/xlevel. The existing
> > X86CPUDefinition.level
have used http://instlatx64.atw.hu/ as a source of CPUID and checked
that it matches Penryn Xeon X5472, Westmere Xeon W3520, SandyBridge
i5-2540M, and Haswell i5-4670T.
kvm64 and qemu64 were bumped to 0xD to allow all available features for
them (and to avoid the same Windows bug).
Signed-off-by:
2015-06-19 11:47+0200, Radim Krčmář:
> 2015-06-18 12:50-0300, Eduardo Habkost:
> > I have considered introducing "min-[x]level" and "max-{x]level"
> > properties to control automatic increasing of level/xlevel. The existing
> > X86CPUDefinition.level
2015-06-19 12:52-0300, Eduardo Habkost:
> On Fri, Jun 19, 2015 at 01:20:40PM +0200, Radim Krčmář wrote:
> [...]
> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > @@ -307,6 +307,24 @@ static void pc_init1(MachineState *machine)
> > static void pc_compat_2
used http://instlatx64.atw.hu/ as a source of CPUID and checked that
it matches Penryn Xeon X5472, Westmere Xeon W3520, SandyBridge i5-2540M,
and Haswell i5-4670T.
kvm64 and qemu64 were bumped to 0xD to allow all available features for
them (and to avoid the same Windows bug).
Signed-off-by:
thout realizing that they are aliases to
CPUID.1H:EDX and have their names there.
See https://bugzilla.redhat.com/show_bug.cgi?id=1326721 for details.
Signed-off-by: Radim Krčmář
---
target-i386/cpu.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
2016-04-15 11:31+0800, Peter Xu:
> This patch allows Intel IR work with splitted irqchip. Two more fields
> are added to IOAPICCommonState to support the translation process (For
> future AMD IR support, we will need to provide another AMD-specific
> callback for int_remap()). In split irqchip mode
2016-04-15 13:54-0300, Eduardo Habkost:
> On Thu, Apr 14, 2016 at 10:55:07PM +0200, Radim Krčmář wrote:
>> QEMU complains about -cpu host on an AMD machine:
>> warning: host doesn't support requested feature: CPUID.8001H:EDX [bit
>> 0]
>> For bits 0,1,3,4,5
eady played with it (hack in EIM cap,
>>> change vtd_remap_irq_get, assuming EIME would be set). However, it
>>> depends on split irqchip to work properly (there is no x2apic in
>>> userspace APIC), and that is not yet the case.
>>
>> That's cool. Never tried it t
2016-04-26 15:34+0800, Peter Xu:
> Hi, Jan,
>
> The above issue should be caused by EOI missing of level-triggered
> interrupts. Before that, I was always using edge-triggered
> interrupts for test, so didn't encounter this one. Would you please
> help try below patch? It can be applied directly o
fine, and piggy-backing them in an MSI message works.
>
> Once KVM supports more CPUs, it has to come up with a new userspace
> interface to inject APIC events for more than 255 CPUs. Maybe the
> existing direct MSI inject with its unused flags could be "bended",
> maybe the
2016-04-26 17:28+0200, Jan Kiszka:
> On 2016-04-26 16:59, Radim Krčmář wrote:
>> 2016-04-26 16:24+0200, Jan Kiszka:
>>> On 2016-04-26 13:40, Peter Xu wrote:
>>>> Currently, all the interrupts will be translated into one MSI in
>>>> vtd_generate_msi_mes
2016-04-27 15:29+0800, Peter Xu:
> On Tue, Apr 26, 2016 at 04:19:00PM +0200, Radim Krčmář wrote:
>> 2016-04-26 15:34+0800, Peter Xu:
>> > diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
>> > @@ -281,6 +281,36 @@ ioapic_mem_read(void *opaque, hwaddr ad
2016-04-28 13:27+0800, Peter Xu:
> On Wed, Apr 27, 2016 at 04:31:13PM +0200, Radim Krčmář wrote:
>
> [...]
>
>> >> > I am still looking into guest part codes. Although the above patch
>> >> > should solve the issue, there are still issues
2016-04-28 15:05+0800, Peter Xu:
> Currently IOAPIC RO bits can be written. To be better aligned with
> hardware, we should let them read-only.
>
> Signed-off-by: Peter Xu
> ---
Reviewed-by: Radim Krčmář
failed to work when IR enabled (tested with Linux
> kernel version 4.5).
>
> Signed-off-by: Peter Xu
> ---
Reviewed-by: Radim Krčmář
2016-04-28 17:18+0800, Peter Xu:
> On Thu, Apr 28, 2016 at 09:19:28AM +0200, Jan Kiszka wrote:
>> Instead of fiddling with irq routes for the IOAPIC - where we don't need
>> it -, I would suggest to do the following: Send IOAPIC events via
>> kvm_irqchip_send_msi to the kernel. Only irqfd users (vh
The memory-mapped interface cannot express x2APIC destinations that are
a result of remapping.
Signed-off-by: Radim Krčmář
---
hw/i386/intel_iommu.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
that delivers extended MSIs
This patch uses latter option, because it was easier for me, but I think
the former one could be a tad nicer.
Signed-off-by: Radim Krčmář
---
hw/i386/kvm/apic.c | 21 ++---
hw/i386/xen/xen_apic.c | 7 +++
hw/intc/apic.c
1 - 100 of 254 matches
Mail list logo
