On 9/21/23 14:11, Nikolay Borisov wrote:
+SYM_FUNC_START(asm_fred_entry_from_kvm)
+ push %rbp
+ mov %rsp, %rbp
use FRAME_BEGIN/FRAME_END macros to ommit this code if
CONFIG_FRAME_POINTER is disabled.
No, the previous stack pointer is used below, so the code might as well
use %rbp for
On 9/14/23 06:48, Xin Li wrote:
When FRED is enabled, call fred_entry_from_kvm() to handle IRQ/NMI in
IRQ/NMI induced VM exits.
Tested-by: Shan Kang
Signed-off-by: Xin Li
Acked-by: Paolo Bonzini
---
arch/x86/kvm/vmx/vmx.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions
On 9/14/23 06:48, Xin Li wrote:
+ /*
+* Don't check the FRED stack level, the call stack leading to this
+* helper is effectively constant and shallow (relatively speaking).
It's more that we don't need to protect from reentrancy. The external
interrupt uses stack level
Il mer 28 giu 2023, 13:28 Bernhard Beschow ha scritto:
>
>
> Am 27. Juni 2023 12:07:40 UTC schrieb Olaf Hering :
> >Tue, 27 Jun 2023 10:12:50 + Bernhard Beschow :
> >
> >> The BAR is a 32 bit register whose default value is 0x0001. I think
> what's supposed to happen here is a pci_set_lon
On 6/26/23 23:19, Olaf Hering wrote:
I need advice on how to debug this.
One thing that stands out is uhci_irq().
It reads a u16 from the USBSTS register.
On the qemu side, this read is served from bmdma_read. Since the read
size is 2, the result is ~0, and uhci_irq() turns the controller off.
On 4/4/23 15:06, Stefan Hajnoczi wrote:
Would this be more useful as a qdev_is_realized() helper?
Yes. There are no other users, but I think a helper makes sense.
Agreed; anyway,
Reviewed-by: Paolo Bonzini
Paolo
On 4/3/23 20:30, Stefan Hajnoczi wrote:
These functions must be called with the AioContext acquired:
/* Callers must hold exp->ctx lock */
void blk_exp_ref(BlockExport *exp)
...
/* Callers must hold exp->ctx lock */
void blk_exp_unref(BlockExport *exp)
Signed-off-by: Stefan Hajno
On 4/3/23 20:29, Stefan Hajnoczi wrote:
The aio_disable_external() API temporarily suspends file descriptor monitoring
in the event loop. The block layer uses this to prevent new I/O requests being
submitted from the guest and elsewhere between bdrv_drained_begin() and
bdrv_drained_end().
While
ue;
qemu_coroutine_yield();
server->wait_idle = false;
}
-assert(server->refcount == 0);
+ assert(server->in_flight == 0);
vu_deinit(vu_dev);
Reviewed-by: Paolo Bonzini
xt();
-aio_disable_external(ctx);
qdev_simple_device_unplug_cb(hotplug_dev, dev, errp);
-aio_enable_external(ctx);
if (s->ctx) {
virtio_scsi_acquire(s);
Reviewed-by: Paolo Bonzini
Queued, thanks.
Paolo
On 11/11/21 11:47, Peter Zijlstra wrote:
This technically could be RCU_INIT_POINTER but it's not worth a respin.
There are dozens of other occurrences, and if somebody wanted they
could use Coccinelle to fix all of them.
I've been pushing the other way, trying to get rid of RCU_INIT_POINTER()
si
a...@vger.kernel.org
Signed-off-by: Sean Christopherson
---
Reviewed-by: Paolo Bonzini
One nit:
EXPORT_SYMBOL_GPL(perf_register_guest_info_callbacks);
int perf_unregister_guest_info_callbacks(struct perf_guest_info_callbacks *cbs)
{
- perf_guest_cbs = NULL;
+ if (
On 11/4/21 15:18, Sean Christopherson wrote:
If I'm interpeting Paolo's suggestion
correctly, he's pointing out that oustanding stores to the function pointers in
@cbs need to complete before assigning a non-NULL pointer to perf_guest_cbs,
otherwise a perf event handler may see a valid pointer wi
On 22/09/21 02:05, Sean Christopherson wrote:
Peter, I left the Intel PT mess as-is. Having to pass a NULL pointer
from KVM arm64 seemed to be a lesser evil than more exports and multiple
registration paths.
This is a combination of ~2 series to fix bugs in the perf+KVM callbacks,
optimize the
andler)(void))
+{
+ kvm_guest_cbs.handle_intel_pt_intr = pt_intr_handler;
+ perf_register_guest_info_callbacks(&kvm_guest_cbs);
+}
+void kvm_unregister_perf_callbacks(void)
+{
+ perf_unregister_guest_info_callbacks(&kvm_guest_cbs);
+}
+#endif
+
struct kvm_cpu_compat_check {
void *opaque;
int *ret;
Reviewed-by: Paolo Bonzini
rn !!vcpu->arch.handling_intr_from_guest;
+}
static inline bool kvm_pat_valid(u64 data)
{
Reviewed-by: Paolo Bonzini
The code is nice, so
Reviewed-by: Paolo Bonzini
Paolo
call_update(__perf_guest_get_ip, (void *)&__static_call_return0);
+ static_call_update(__perf_guest_handle_intel_pt_intr,
+ (void *)&__static_call_return0);
synchronize_rcu();
}
EXPORT_SYMBOL_GPL(perf_unregister_guest_info_callbacks);
Reviewed-by: Paolo Bonzini
ERF_EVENTS */
Reviewed-by: Paolo Bonzini
Having perf_guest_handle_intel_pt_intr in generic code is a bit off. Of
course it has to be in the struct, but the wrapper might be placed in
arch/x86/include/asm/perf_event.h as well (applies to patch 7 as well).
Paolo
est_cbs->handle_intel_pt_intr();
+ return 0;
+}
extern void perf_register_guest_info_callbacks(struct
perf_guest_info_callbacks *cbs);
extern void perf_unregister_guest_info_callbacks(struct
perf_guest_info_callbacks *cbs);
Reviewed-by: Paolo Bonzini
ame_f)(char *name, int name_len, void *data);
Reviewed-by: Paolo Bonzini
e guest, and drop "guest" from ->is_in_guest.
... from ->get_guest_ip. Code-wise,
Reviewed-by: Paolo Bonzini
not support perf in guest mode. */
- if (guest_cbs && guest_cbs->is_in_guest()) {
- pr_warn("RISC-V does not support perf in guest mode!");
- return;
- }
-
walk_stackframe(NULL, regs, fill_callchain, entry);
}
Reviewed-by: Paolo Bonzini
cbs, NULL);
synchronize_rcu();
- return 0;
}
EXPORT_SYMBOL_GPL(perf_unregister_guest_info_callbacks);
Apart from the above,
Reviewed-by: Paolo Bonzini
rch_hardware_setup(void *opaque)
void kvm_arch_hardware_unsetup(void)
{
perf_unregister_guest_info_callbacks(&kvm_guest_cbs);
+ kvm_guest_cbs.handle_intel_pt_intr = NULL;
static_call(kvm_x86_hardware_unsetup)();
}
Acked-by: Paolo Bonzini
r_guest_info_callbacks(&kvm_guest_cbs);
+
static_call(kvm_x86_hardware_unsetup)();
}
Acked-by: Paolo Bonzini
On 28/08/21 21:47, Peter Zijlstra wrote:
+config HAVE_GUEST_PERF_EVENTS
+ bool
depends on HAVE_KVM
It won't really do anything, since Kconfig does not detects conflicts
between select' and 'depends on' clauses.
Rather, should the symbol be selected by KVM, instead of ARM64 and
On 20/09/21 15:40, Marc Zyngier wrote:
At least not before we
declare the arm64 single kernel image policy to be obsolete.
--verbose please.:) I am sure you're right, but I don't understand
the link between the two.
To start making KVM/arm64 modular, you'd have to build it such as
there is
On 20/09/21 14:22, Marc Zyngier wrote:
I think that's only ARM, and even then it is only because of
limitations of the hardware which mostly apply only if VHE is not in
use.
If anything, it's ARM that should support module build in VHE mode
(Linux would still need to know whether it will be runn
On 17/09/21 09:28, Peter Zijlstra wrote:
In theory, I like the idea of burying intel_pt inside x86 (and even in
Intel+VMX code for the most part), but the actual implementation is a
bit gross. Because of the whole "KVM can be a module" thing,
ARGH!! we should really fix that. I've heard other
On 09/09/21 01:20, Philippe Mathieu-Daudé wrote:
+static QemuOptsList qemu_security_policy_opts = {
+.name = "security-policy",
+.implied_opt_name = "policy",
+.merge_lists = true,
+.head = QTAILQ_HEAD_INITIALIZER(qemu_security_policy_opts.head),
+.desc = {
+{
+
On 22/07/21 16:12, Anthony PERARD via wrote:
Reviewed-by: Anthony PERARD
I can't find a different way to set a default "accelerator" to a
machine, so this patch seems necessary.
I agree, and I'll be sending a pull request shortly.
Paolo
On 28/04/21 23:27, Steven Rostedt wrote:
On Tue, 27 Apr 2021 07:09:46 +0800
Lai Jiangshan wrote:
From: Lai Jiangshan
There is no any functionality change intended. Just rename it and
move it to arch/x86/kernel/nmi.c so that we can resue it later in
next patch for early NMI and kvm.
Nit, b
On 25/03/21 12:12, Olaf Hering wrote:
Am Mon, 22 Mar 2021 18:09:17 -0400
schrieb John Snow :
My understanding is that XEN has some extra disks that it unplugs when
it later figures out it doesn't need them. How exactly this works is
something I've not looked into too closely.
It has no extra
On 08/03/21 19:14, Anthony PERARD wrote:
On Mon, Mar 08, 2021 at 06:37:38PM +0100, Paolo Bonzini wrote:
On 08/03/21 18:29, Anthony PERARD wrote:
If nothing else works then I guess it's okay, but why can't you do the
xen_block_drive_destroy from e.g. an unrealize callback?
I
On 08/03/21 18:29, Anthony PERARD wrote:
If nothing else works then I guess it's okay, but why can't you do the
xen_block_drive_destroy from e.g. an unrealize callback?
I'm not sure if that's possible.
xen_block_device_create/xen_block_device_destroy() is supposed to be
equivalent to do those
On 08/03/21 15:32, Anthony PERARD wrote:
From: Anthony PERARD
Whenever a Xen block device is detach via xenstore, the image
associated with it remained open by the backend QEMU and an error is
logged:
qemu-system-i386: failed to destroy drive: Node xvdz-qcow2 is in use
This happened since
On 02/02/21 16:56, Philippe Mathieu-Daudé wrote:
'drivers_blacklisted' is never accessed, remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen_platform.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xe
On 01/02/21 11:59, Philippe Mathieu-Daudé wrote:
On 1/31/21 3:18 PM, Philippe Mathieu-Daudé wrote:
xenpv machine requires USB, IDE_PIIX and PCI:
/usr/bin/ld:
libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
`xen_be_register_common':
hw/xen/xen-legacy-backend.c:757: undefined
On 01/02/21 10:18, Philippe Mathieu-Daudé wrote:
FYI using 'imply FSDEV_9P' instead I get:
/usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
`xen_be_register_common':
hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops'
Ok, so then we have the case of a f
On 31/01/21 15:18, Philippe Mathieu-Daudé wrote:
9pfs is not an accelerator feature but a machine one,
move the selection on the machine Kconfig (in hw/).
Signed-off-by: Philippe Mathieu-Daudé
---
accel/Kconfig | 1 -
hw/i386/xen/Kconfig | 1 +
hw/xen/Kconfig | 1 +
3 files chan
On 29/01/21 20:44, Philippe Mathieu-Daudé wrote:
xenpv machine requires USB, IDE_PIIX and PCI:
/usr/bin/ld:
libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
`xen_be_register_common':
hw/xen/xen-legacy-backend.c:757: undefined reference to `xen_usb_ops'
libqemu-i386-softmmu.
On 29/01/21 20:44, Philippe Mathieu-Daudé wrote:
hw/ide/piix.c has a strong dependency on hw/isa/isa-bus.c:
/usr/bin/ld: libcommon.fa.p/hw_ide_piix.c.o: in function
`pci_piix_init_ports':
/usr/bin/ld: hw/ide/piix.c:141: undefined reference to `isa_get_irq'
Signed-off-by: Philippe Mathieu
On 29/01/21 20:44, Philippe Mathieu-Daudé wrote:
hw/ide/ioport.c has a strong dependency on hw/isa/isa-bus.c:
/usr/bin/ld: libcommon.fa.p/hw_ide_ioport.c.o: in function `ide_init_ioport':
/usr/bin/ld: hw/ide/ioport.c:61: undefined reference to
`isa_register_portio_list'
Signed-off-by: Ph
On 10/12/20 14:47, marcandre.lur...@redhat.com wrote:
From: Marc-André Lureau
Hi,
Since commit efc6c07 ("configure: Add a test for the minimum compiler version"),
QEMU explicitely depends on GCC >= 4.8.
v3:
- drop first patch replacing QEMU_GNUC_PREREQ with G_GNUC_CHECK_VERSION
- add last
On 10/12/20 15:32, Philippe Mathieu-Daudé wrote:
On 12/10/20 2:47 PM, marcandre.lur...@redhat.com wrote:
From: Marc-André Lureau
Since commit efc6c07 ("configure: Add a test for the minimum compiler
version"), QEMU explicitely depends on GCC >= 4.8.
(clang >= 3.4 advertizes itself as GCC >= 4
On 06/11/20 20:03, Christoph Hellwig wrote:
revalidate_disk_size just updates the block device size from the disk
size. Thus calling it from revalidate_disk_size doesn't actually do
s/revalidate_disk_size/virtblk_update_cache_mode/
anything.
On 05/11/20 03:48, Stefano Stabellini wrote:
I repeated all the steps to make sure. The first time I was using
Samurai because Alpine Linux comes with it and not Ninja. Then, I
removed Samurai and built and installed Ninja by hand from
https://github.com/ninja-build/ninja and that actually works.
0x38): undefined
reference to `proxy_ops'
collect2: error: ld returned 1 exit status
Fixes: b2c00bce54c ("meson: convert hw/9pfs, cleanup")
Suggested-by: Paolo Bonzini
Signed-off-by: Philippe Mathieu-Daudé
---
I'm not sure b2c00bce54c is the real culprit
I think it is, probably a wrong conflict resolution.
Paolo
Il mer 4 nov 2020, 03:27 Stefano Stabellini ha
scritto:
> FYI I tried to build the latest QEMU on Alpine Linux 3.12 ARM64 and I
> get:
>
> ninja: unknown tool 'query'
>
> Even after rebuilding ninja master by hand. Any ideas? I don't know much
> about ninja.
>
Are you sure you have ninja insta
On 29/10/20 23:12, David Laight wrote:
>> https://godbolt.org/z/4dzPbM
>>
>> With -fno-strict-aliasing, the compiler reloads the pointer if you write
>> to the start of what it points to, but not if you write to later
>> elements.
> I guess it assumes that global data doesn't overlap.
Yeah, settin
On 30/10/20 12:35, Eduardo Habkost wrote:
>
> What is necessary to make sure we have a CONFIG_XEN=y job in
> gitlab CI? Maybe just including xen-devel in some of the
> container images is enough?
Fedora already has it, but build-system-fedora does not include
x86_64-softmmu.
Paolo
On 29/10/20 17:56, Arvind Sankar wrote:
>> For those two just add:
>> struct apic *apic = x86_system_apic;
>> before all the assignments.
>> Less churn and much better code.
>>
> Why would it be better code?
>
I think he means the compiler produces better code, because it won't
read the glob
On 28/10/20 22:20, Arnd Bergmann wrote:
> Avoid this by renaming the global 'apic' variable to the more descriptive
> 'x86_system_apic'. It was originally called 'genapic', but both that
> and the current 'apic' seem to be a little overly generic for a global
> variable.
The 'apic' affects only th
On 23/10/20 09:09, Thomas Huth wrote:
> On 22/10/2020 17.29, Paolo Bonzini wrote:
>> On 22/10/20 17:17, Jason Andryuk wrote:
>>> On Tue, Oct 13, 2020 at 1:16 PM Paolo Bonzini wrote:
>>>>
>>>> On 13/10/20 16:05, Jason Andryuk wrote:
>>>>>
On 22/10/20 17:17, Jason Andryuk wrote:
> On Tue, Oct 13, 2020 at 1:16 PM Paolo Bonzini wrote:
>>
>> On 13/10/20 16:05, Jason Andryuk wrote:
>>> Xen was left behind when CpusAccel became mandatory and fails the assert
>>> in qemu_init_vcpu(). It relied on th
pus.c => dummy-cpus.c} (71%)
> delete mode 100644 accel/qtest/qtest-cpus.h
>
Acked-by: Paolo Bonzini
o the pull request.
>
If it counts, :) for patch 1-4:
Acked-by: Paolo Bonzini
Generally these patches to remove code from user-mode emulators
fall into the "if it builds it's fine" bucket, since I assume
we want the "misc" subschema to be as small as possible.
Paolo
On 02/10/20 18:43, Matthew Rosato wrote:
>> diff --git
>> a/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h
>> b/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h
>> index acd4c8346d..7b4062a1a1 100644
>> ---
>> a/include/standard-headers/drivers/infini
On 22/09/20 10:58, Stefan Hajnoczi wrote:
> clang's C11 atomic_fetch_*() functions only take a C11 atomic type
> pointer argument. QEMU uses direct types (int, etc) and this causes a
> compiler error when a QEMU code calls these functions in a source file
> that also included via a system header f
On 08/09/20 17:55, Philippe Mathieu-Daudé wrote:
> Hard to make an exciting cover of this series.
>
> Basically:
> - Make better separation between Xen accel and Xen hardware,
> - Move stuff around to restrict PCMachineState to hw/i386/.
>
> Since v1:
> - added missing include in stubs/xen-hw-stu
On 22/09/20 08:45, David Hildenbrand wrote:
>> It's certainly a good idea but it's quite verbose.
>>
>> What about using atomic__* as the prefix? It is not very common in QEMU
>> but there are some cases (and I cannot think of anything better).
>
> aqomic_*, lol :)
Actually qatomic_ would be a go
On 21/09/20 18:23, Stefan Hajnoczi wrote:
> clang's C11 atomic_fetch_*() functions only take a C11 atomic type
> pointer argument. QEMU uses direct types (int, etc) and this causes a
> compiler error when a QEMU code calls these functions in a source file
> that also included via a system header f
On 22/07/20 10:25, Philippe Mathieu-Daudé wrote:
> Xen accelerator requires specific changes to a machine to be able
> to use it. See for example the 'Xen PC' machine configure its PCI
> bus calling pc_xen_hvm_init_pci(). There is no 'Xen Q35' machine
> declared. This code was probably added while
On 04/07/20 21:44, BALATON Zoltan wrote:
>
> No it's OK, no need to list all defines. I just did not notice the macro
> argument that's why I was wondering where it comes from. This seems to
> be used elsewhere at least here:
>
> hw/audio/es1370.c:#define a(n) if (val & CTRL_##n) strcat (buf, " "
On 19/06/20 12:31, Anthony PERARD wrote:
> Fix typo.
>
> Fixes: acd0c9416d48 ("xen: fix build without pci passthrough")
> Signed-off-by: Anthony PERARD
> ---
> hw/xen/Makefile.objs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.ob
On 08/06/20 18:17, Philippe Mathieu-Daudé wrote:
> On 6/8/20 6:14 PM, Peter Maydell wrote:
>> On Mon, 8 Jun 2020 at 17:00, Philippe Mathieu-Daudé
>> wrote:
>>>
>>> Based on today's IRC chat, this is a trivial RFC series
>>> to anotate pre-qdev/QOM devices so developers using them
>>> without know
On 08/06/20 18:00, Philippe Mathieu-Daudé wrote:
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/openrisc/cputimer.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/hw/openrisc/cputimer.c b/hw/openrisc/cputimer.c
> index 932
On 08/06/20 18:00, Philippe Mathieu-Daudé wrote:
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/ppc/virtex_ml507.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/hw/ppc/virtex_ml507.c b/hw/ppc/virtex_ml507.
On 08/06/20 18:00, Philippe Mathieu-Daudé wrote:
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/ppc/ppc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
> index 4a11fb1640..39fcf746c5 100644
> -
On 08/06/20 18:00, Philippe Mathieu-Daudé wrote:
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/ppc/ppc_booke.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/hw/ppc/ppc_booke.c b/hw/ppc/ppc_booke.c
> index
On 08/06/20 18:00, Philippe Mathieu-Daudé wrote:
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/intc/i8259.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c
> index 51b27f6a34..9d9609cdab 1
On 08/06/20 18:00, Philippe Mathieu-Daudé wrote:
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/lm32/lm32_hwsetup.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/hw/lm32/lm32_hwsetup.h b/hw/lm32/lm32_hwsetup.h
> index de9
On 08/06/20 18:00, Philippe Mathieu-Daudé wrote:
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/timer/arm_timer.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/hw/timer/arm_timer.c b/hw/timer/arm_timer.c
> index 9607366d7
On 08/06/20 18:00, Philippe Mathieu-Daudé wrote:
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/i386/pc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 2128f3d6fe..c71809fd28 100644
> -
clude "hw/qdev-deprecated.h"
> #include "trace.h"
>
> /* Keyboard Controller Commands */
> @@ -467,6 +467,8 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
> {
> KBDState *s = g_malloc0(sizeof(KBDState));
>
> +qdev_warn_deprecated_f
On 08/06/20 18:00, Philippe Mathieu-Daudé wrote:
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/input/ps2.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/hw/input/ps2.c b/hw/input/ps2.c
> index f8746d2f5
dr base,
> Chardev *chr, qemu_irq irq)
> {
> SiFiveUARTState *s = g_malloc0(sizeof(SiFiveUARTState));
> +
> +qdev_warn_deprecated_function_used();
> +
> s->irq = irq;
> qemu_chr_fe_init(&s->chr, chr, &error_abort);
> qemu_chr_fe_set_handlers(&s->chr, uart_can_rx, uart_rx, uart_event,
>
Reviewed-by: Paolo Bonzini
Not sure why this code was accepted, furthermore it should have been in
hw/char.
Paolo
On 08/06/20 18:00, Philippe Mathieu-Daudé wrote:
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/misc/applesmc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/hw/misc/applesmc.c b/hw/misc/applesmc.c
> index 1c4addb201..d63
On 08/06/20 18:00, Philippe Mathieu-Daudé wrote:
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/timer/slavio_timer.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
> index
On 04/06/20 15:30, Anthony PERARD wrote:
> - fix build when Xen headers aren't available.
> By building stubs/xen-pt.c only when CONFIG_XEN=y
> (The alternative would be to move the prototypes used by the stub into
> xen.h, which doesn't depends on xen headers.)
Good catch.
On 03/06/20 18:04, Anthony PERARD wrote:
> From: Roger Pau Monne
>
> Xen PCI passthrough support may not be available and thus the global
> variable "has_igd_gfx_passthru" might be compiled out. Common code
> should not access it in that case.
>
> Unfortunately, we can't use CONFIG_XEN_PCI_PASST
On 08/05/20 12:02, Philippe Mathieu-Daudé wrote:
> This code is not related to hardware emulation.
> Move it under accel/ with the other hypervisors.
>
> Reviewed-by: Paul Durrant
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> We could also move the memory management functions from
> hw/i386/xe
On 19/05/20 06:34, Markus Armbruster wrote:
> Cédric Le Goater writes:
>
>> On 5/18/20 3:17 PM, Markus Armbruster wrote:
>>> Paolo Bonzini writes:
>>>
>>>> On 15/05/20 07:58, Markus Armbruster wrote:
>>>>> Philippe Mathieu-Daudé write
On 15/05/20 07:58, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> Remove unnecessary casts using coccinelle scripts.
>>
>> The CPU()/OBJECT() patches don't introduce logical change,
>> The DEVICE() one removes various OBJECT_CHECK() calls.
> Queued, thanks!
>
> Managing expecatio
On 04/03/20 15:12, Philippe Mathieu-Daudé wrote:
> I'll send a fix for the dangerous code.
> Do you want to drop this series, or only the change in 'struct srp_rsp'
> (or in all hw/scsi/srp.h). Actually I guess it makes sense I move the
> 'hw/scsi/srp.h' changes with the series cleaning dangerous c
On 04/03/20 14:12, Philippe Mathieu-Daudé wrote:
>
> hw/scsi/spapr_vscsi.c:69:29: error: field 'iu' with variable sized type
> 'union viosrp_iu' not at the end of a struct or class is a GNU extension
> [-Werror,-Wgnu-variable-sized-type-not-at-end]
> union viosrp_iu iu;
>
On 04/03/20 01:51, Philippe Mathieu-Daudé wrote:
> This is a tree-wide cleanup inspired by a Linux kernel commit
> (from Gustavo A. R. Silva).
>
> --v-- description start --v--
>
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the prefer
On 26/10/19 15:32, Laurent Vivier wrote:
> Le 26/10/2019 à 14:20, Philippe Mathieu-Daudé a écrit :
>> Hi,
>>
>> On 10/14/19 4:22 PM, Philippe Mathieu-Daudé wrote:
>>> This is a follow-up of Markus's cleanup series:
>>> Tame a few "touch this, recompile the world"
>>> https://www.mail-archive.com/qe
On 20/02/20 14:05, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/exec/cpu-common.h | 6 +++---
> include/sysemu/xen-mapcache.h | 4 ++--
> exec.c| 8
> hw/i386/xen/xen-mapcache.c| 2 +-
> 4 files changed, 10 insertio
On 18/02/20 19:49, Peter Maydell wrote:
> Depending on which way we go we would either want to remove these
> casts, or not.
>
> I guess that we have more cases of 'void*', and that would
> certainly be the easier way to convert (otherwise we probably
> need to add a bunch of new casts to uint8_t*
On 18/12/19 12:57, Laurent Vivier wrote:
> Le 09/12/2019 à 11:05, Thomas Huth a écrit :
>> On 09/12/2019 10.49, Philippe Mathieu-Daudé wrote:
>>> We don't enforce the -Wsign-conversion CPPFLAG, but it doesn't hurt
>>> to avoid this warning:
>>>
>>> warning: implicit conversion changes signedness:
On 16/12/19 16:37, Philippe Mathieu-Daudé wrote:
> On 12/15/19 10:58 AM, Michael S. Tsirkin wrote:
>> On Fri, Dec 13, 2019 at 05:47:28PM +0100, Philippe Mathieu-Daudé wrote:
>>> On 12/13/19 5:17 PM, Philippe Mathieu-Daudé wrote:
Historically, QEMU started with only one X86 machine: the PC.
>>>
On 13/12/19 17:17, Philippe Mathieu-Daudé wrote:
> The "pcie_host.h" header is used by devices providing a PCI-e bus,
> usually North Bridges. The ICH9 is a South Bridge.
> Since we don't need this header, do not include it.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/hw/i386/ich9.
On 13/12/19 17:17, Philippe Mathieu-Daudé wrote:
> Using magic numbers is dangerous because the structures PCIIDEState
> might be modified and this source file consuming the "ide/pci.h"
> header would be out of sync, eventually accessing out of bound
> array members.
> Use the ARRAY_SIZE() to keep
On 13/12/19 17:17, Philippe Mathieu-Daudé wrote:
> Since commit 0c8465440 the ioapic_print_redtbl() function is not
> used outside of ioapic_common.c, make it static, and remove its
> prototype declaration in "ioapic_internal.h".
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/hw/i386/
On 13/12/19 17:17, Philippe Mathieu-Daudé wrote:
> While the ICH9 chipset is a 'South Bridge', it is not a PCI bridge.
> Nothing in "hw/i386/ich9.h" requires definitions from "pci_bridge.h"
> so move its inclusion where it is required.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/hw
On 13/12/19 17:17, Philippe Mathieu-Daudé wrote:
> Commit 02a9594b4f0 already converted 'dev' to DeviceState.
> Since the cast is superfluous, remove it.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/ide/piix.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw
On 13/12/19 17:17, Philippe Mathieu-Daudé wrote:
> In commit f809c6051 we replaced the use of cpu_set_smm_t callbacks
> by using a Notifier to modify the MemoryRegion. This prototype is
> now not used anymore, we can safely remove it.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/hw/
1 - 100 of 165 matches
Mail list logo
