Re: [Qemu-devel] [PATCH v3 03/16] s390: Convert debug printfs to QEMU_DPRINTF
On Tue, May 20, 2014 at 2:50 AM, Richard Henderson wrote: > On 05/19/2014 09:45 AM, Marc Marí wrote: >>> > This STDOUT vs _log() choice is a bit irregular, and I think you might >>> > be better off abandoning it completely. Richard, Alex, do we really >>> > need to optionally route printfery to log or stderr? (considering _log >>> > is NOW stderr by default now, and -D option gives you some flexibility >>> > there). Can we have just log and drop STDOUT mode? >>> > >>> > Regards, >>> > Peter >> QEMU_DPRINTF outputs to stderr, and, as you say qemu_log does it too. >> Should QEMU_DPRINTF be removed and leave only qemu_log? Ahh I see now, you want to use the common factored-out code in P1 which is stderr specific. Perhaps that should use qemu_log. One option would be to create a variant of it in common code that does uses qemu_log instead of stderr and use that variant here. That way you can preserve existing behaviour (and maintainer expectations), as much as possible. > > Yes, I think that all debug output like this should go via qemu_log. > Thanks. Regards, Peter > > r~ > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v3 03/16] s390: Convert debug printfs to QEMU_DPRINTF
On Sun, May 18, 2014 at 9:03 AM, Marc Marí wrote:
> Modify debug macros to have the same format through the codebase and use
> regular
> ifs instead of ifdef.
>
> Signed-off-by: Marc Marí
> ---
> hw/s390x/s390-virtio-bus.c |9 +
> hw/s390x/s390-virtio.c |9 +
> target-s390x/helper.c | 23 +++
> target-s390x/kvm.c |9 +
> 4 files changed, 30 insertions(+), 20 deletions(-)
>
> diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c
> index 9c71afa..2a1799e 100644
> --- a/hw/s390x/s390-virtio-bus.c
> +++ b/hw/s390x/s390-virtio-bus.c
> @@ -38,13 +38,14 @@
> /* #define DEBUG_S390 */
>
> #ifdef DEBUG_S390
> -#define DPRINTF(fmt, ...) \
> -do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
> +#define DEBUG_S390_ENABLED 1
> #else
> -#define DPRINTF(fmt, ...) \
> -do { } while (0)
> +#define DEBUG_S390_ENABLED 0
> #endif
>
> +#define DPRINTF(fmt, ...) \
> +QEMU_DPRINTF(DEBUG_S390_ENABLED, "s390 virtio bus", fmt, ## __VA_ARGS__)
> +
> #define VIRTIO_EXT_CODE 0x2603
>
> static void virtio_s390_bus_new(VirtioBusState *bus, size_t bus_size,
> diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
> index aef2003..b69afb4 100644
> --- a/hw/s390x/s390-virtio.c
> +++ b/hw/s390x/s390-virtio.c
> @@ -42,13 +42,14 @@
> //#define DEBUG_S390
>
> #ifdef DEBUG_S390
> -#define DPRINTF(fmt, ...) \
> -do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
> +#define DEBUG_S390_ENABLED 1
> #else
> -#define DPRINTF(fmt, ...) \
> -do { } while (0)
> +#define DEBUG_S390_ENABLED 0
> #endif
>
> +#define DPRINTF(fmt, ...) \
> +QEMU_DPRINTF(DEBUG_S390_ENABLED, "s390 virtio", fmt, ## __VA_ARGS__)
> +
> #define MAX_BLK_DEVS10
> #define ZIPL_FILENAME "s390-zipl.rom"
>
> diff --git a/target-s390x/helper.c b/target-s390x/helper.c
> index 7c76fc1..c2aa568 100644
> --- a/target-s390x/helper.c
> +++ b/target-s390x/helper.c
> @@ -30,19 +30,26 @@
> //#define DEBUG_S390_STDOUT
>
> #ifdef DEBUG_S390
> -#ifdef DEBUG_S390_STDOUT
> -#define DPRINTF(fmt, ...) \
> -do { fprintf(stderr, fmt, ## __VA_ARGS__); \
> - qemu_log(fmt, ##__VA_ARGS__); } while (0)
> +#define DEBUG_S390_ENABLED 1
> #else
> -#define DPRINTF(fmt, ...) \
> -do { qemu_log(fmt, ## __VA_ARGS__); } while (0)
> +#define DEBUG_S390_ENABLED 0
> #endif
> +
> +#ifdef DEBUG_S390_STDOUT
This STDOUT vs _log() choice is a bit irregular, and I think you might
be better off abandoning it completely. Richard, Alex, do we really
need to optionally route printfery to log or stderr? (considering _log
is NOW stderr by default now, and -D option gives you some flexibility
there). Can we have just log and drop STDOUT mode?
Regards,
Peter
> +#define DEBUG_S390_STDOUT_ENABLED 1
> #else
> -#define DPRINTF(fmt, ...) \
> -do { } while (0)
> +#define DEBUG_S390_STDOUT_ENABLED 0
> #endif
>
> +#define DPRINTF(fmt, ...) \
> +do { \
> +if(DEBUG_S390_ENABLED) { \
> +qemu_log(fmt, ##__VA_ARGS__); \
> +QEMU_DPRINTF(DEBUG_S390_STDOUT_ENABLED, "s390x helper", \
> +fmt, ## __VA_ARGS__); \
> +} \
> +} while (0)
> +
> #ifdef DEBUG_S390_PTE
> #define PTE_DPRINTF DPRINTF
> #else
> diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
> index 56179af..63c46c4 100644
> --- a/target-s390x/kvm.c
> +++ b/target-s390x/kvm.c
> @@ -41,13 +41,14 @@
> /* #define DEBUG_KVM */
>
> #ifdef DEBUG_KVM
> -#define DPRINTF(fmt, ...) \
> -do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
> +#define DEBUG_KVM_ENABLED 1
> #else
> -#define DPRINTF(fmt, ...) \
> -do { } while (0)
> +#define DEBUG_KVM_ENABLED 0
> #endif
>
> +#define DPRINTF(fmt, ...) \
> +QEMU_DPRINTF(DEBUG_KVM_ENABLED, "s390 kvm", fmt, ## __VA_ARGS__)
> +
> #define IPA0_DIAG 0x8300
> #define IPA0_SIGP 0xae00
> #define IPA0_B2 0xb200
> --
> 1.7.10.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for 2014-05-13
On Mon, May 12, 2014 at 9:09 PM, Peter Maydell wrote: > On 12 May 2014 11:30, Peter Crosthwaite wrote: >> On Mon, May 12, 2014 at 7:44 PM, Peter Maydell >> wrote: >>> On 12 May 2014 10:10, Juan Quintela wrote: >>>> Please, send any topic that you are interested in covering. >>>> >>>> - QOMifying both Memory regions and GPIOs and attaching them via QOM >>>> links (Peter Crosthwaite) >>> >>> Is there some further useful material on-list on this subject, or >>> are we just going to have a rerun of the discussions on the >>> last two calls? > >> I have any ugly work-in-progress series. TBH I was going to wait for >> discussion outcomes. Want me to RFC it? > > I don't think you necessarily need to post code, but maybe a writeup > of current status/options would be useful to try to make the on-call > discussion productive? > Ok so here's my plan: QOMify address spaces. So they can be instantiated, reffed etc. completely aside from the hotplug discussion this greatly helps connecting bus master devices using proper QOM links. E.G. using machine-set link properties rather &address_space_memory everywhere. QOMify Memory regions. So they are added as child objects to devices. Devices can do this explicitly in instance_init, or sysbus can handle it - sysbus_init_mmio parents the memory region to the device to transparently convert all existing devs to compliance. The address and container (the memory region containing this one as a subregion) of memory regions are QOM properties, of type integer and link resp. Setting the properties does the memory_region_add_subregion(). The root address space is parented the machine in exec.c. This give the address space a canonical path. Its root memory region is a child of it, so it also is referencable by canon path. Sysbus IRQ are abandoned completely and re-implemented as named GPIOs. The sysbus irq API remains and makes this transition behind-the-scenes. GPIOs are QOMified. qemu_allocate_irqs does the object_new() etc. IRQ inputs are then added as child objects of the instantiating device. Handled by qemu_init_gpio_in_named(). gpio_outs are setup as links. qdev_connect_gpio_out does the linkage. QOM is patched to allow setting of a device's child's properties from a ref to the parent. Best illustrated by example (see below). Anyways without a single patch to the command line interface, HMP, QMP, or implementing any machine specific hotplug or adding any new special busses, this works: -device xlnx.xps-timer,\ sysbus-mr-0.container=/machine/sysmem/root-mr,\ sysbus-mr-0.addr=0x83c0,\ sysbus-irq-0=/machine/intc/unnamed-gpio-0 All the other ways to create devices should just work, this is not a command line specific feature. Note, I edited my machine model to sanitize the canonical path of the interrupt controller: --- a/hw/microblaze/petalogix_s3adsp1800_mmu.c +++ b/hw/microblaze/petalogix_s3adsp1800_mmu.c @@ -97,6 +97,8 @@ petalogix_s3adsp1800_init(QEMUMachineInitArgs *args) 1, 0x89, 0x18, 0x, 0x0, 1); dev = qdev_create(NULL, "xlnx.xps-intc"); +object_property_add_child(qdev_get_machine(), "intc", OBJECT(dev), + &error_abort); But you could have done the whole /machine/unattached/... ugliness too. If you name the irq inputs in the intc with my named GPIO series stuff the unnamed-gpio ugliness goes away too. If you throw away sysbus and do the memory-regions and IRQs naming the child objects properly the ugly sysbus names can de dispensed with too. But thats a big tree-wide to name everything properly. Regards, Peter > thanks > -- PMM > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for 2014-05-13
On Mon, May 12, 2014 at 7:44 PM, Peter Maydell wrote: > On 12 May 2014 10:10, Juan Quintela wrote: >> Please, send any topic that you are interested in covering. >> >> - QOMifying both Memory regions and GPIOs and attaching them via QOM >> links (Peter Crosthwaite) > > Is there some further useful material on-list on this subject, or > are we just going to have a rerun of the discussions on the > last two calls? > I have any ugly work-in-progress series. TBH I was going to wait for discussion outcomes. Want me to RFC it? Regards, Peter > thanks > -- PMM > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for 2014-04-29
On Wed, Apr 30, 2014 at 1:20 AM, Juan Quintela wrote: > > > 2014-04-29 > -- > > - security (CVE) > New group to handle that issues responsible. > Mail is still not encrypted, wolud be. > mst writing a wiki page about it > what is the criteria to request (not) for a CVE number > Look at http://wiki.qemu.org/SecurityProcess > > - hot [un]plug for passthrough devices for platform devices > > Lots of discussions about how to do it internally/externally from > qemu, both with its [dis]advantages. Basically how to do things > there. > Iv'e had a play with QOMifying both Memory regions and GPIOs and attaching them via QOM links. Looks viable as a unified solution. Can we discuss at next call? Regards, Peter > > Later, Juan. > > > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
