Re: [Xen-devel] [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 29/11/2017 15:25, Boris Ostrovsky wrote: zeropage is x86/Linux-specific so we'd need some sort of firmware (like grub) between a hypervisor and Linux to convert hvm_start_info to bootparams. >>> qemu? > > I think KVM folks didn't want to do this. I can't find the thread but I >

Re: [Xen-devel] [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 29/11/2017 15:47, Juergen Gross wrote: > On 29/11/17 15:44, Paolo Bonzini wrote: >> In either case, you would have a new option ROM. It could either be >> very simple and similar to multiboot.S, or it could be larger and do the >> same task as xen-pvh.S and enli

Re: [Xen-devel] [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 29/11/2017 18:14, Maran Wilson wrote: > That is one option. I guess this gets into a discussion about the QEMU > side of the upcoming patches that would follow ... > > I'm currently just initializing the CPU state in QEMU for testing since > there is such minimal (non Linux specific) setup

Re: [Xen-devel] BSOD with [PATCH 00/13] mmu_notifier kill invalidate_page callback

On 30/11/2017 10:33, Fabian Grünbichler wrote: > > It was reverted in 785373b4c38719f4af6775845df6be1dfaea120f after which > the symptoms disappeared until this series was merged, which contains > > 369ea8242c0fb5239b4ddf0dc568f694bd244de4 mm/rmap: update to new mmu_notifier > semantic v2 > >

Re: [Xen-devel] [RFC PATCH v3 2/2] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 15/12/2017 16:55, Juergen Gross wrote: > I'm fine with the general idea. > > I'm wondering whether you really want to require CONFIG_XEN for the > KVM case, though. > > Wouldn't it be better to rename arch/x86/xen/enlighten_pvh.c to > arch/x86/pvh.c and arch/x86/xen/xen-pvh.S to

Re: [Xen-devel] [RFC PATCH v2 1/2] xen/pvh: Add memory map pointer to hvm_start_info struct

On 08/12/2017 09:49, Jan Beulich wrote: >> + * The layout of each entry in the memory map table is as follows and no >> + * padding is used between entries in the array: >> + * >> + * 0 ++ >> + *| addr | Base address >> + * 8 ++ >> + *| size

Re: [Xen-devel] [RFC PATCH v2 1/2] xen/pvh: Add memory map pointer to hvm_start_info struct

On 12/12/2017 09:06, Jan Beulich wrote: On 11.12.17 at 22:59, wrote: >> On 08/12/2017 09:49, Jan Beulich wrote: + * The layout of each entry in the memory map table is as follows and no + * padding is used between entries in the array: + * + * 0

Re: [Xen-devel] [PATCH 0/3] Document intent for supported build platforms and bump min glib to 2.42

On 08/05/2018 16:50, George Dunlap wrote: > Tailing into that, with my CentOS package maintainer hat on: You said > that the code in question compiled on RHEL 6 because RH had backported > the function in question. Will QEMU continue to actually compile on > RHEL 6 / CentOS 6? I.e., will

Re: [Xen-devel] [PATCH v7 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 16/05/2018 22:27, Maran Wilson wrote: > Friendly ping. I am hopeful one of the x86 and/or KVM maintainers has a > few cycles to spare to look this over. > > And thanks to everyone who has helped thus far by providing valuable > feedback and reviewing. > >   

Re: [Xen-devel] [PATCH] xen-hvm: stop faking I/O to access PCI config space

Tsirkin" <m...@redhat.com> > Cc: Marcel Apfelbaum <mar...@redhat.com> > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Richard Henderson <r...@twiddle.net> > Cc: Eduardo Habkost <ehabk...@redhat.com> > --- > hw/i386/xen/trace-events | 2 + >

Re: [Xen-devel] [PATCH v2 16/17] driver/edac: enable Hygon support to AMD64 EDAC driver

On 23/07/2018 15:20, Pu Wen wrote: > @@ -211,7 +211,7 @@ static int __set_scrub_rate(struct amd64_pvt *pvt, u32 > new_bw, u32 min_rate) > > scrubval = scrubrates[i].scrubval; > > - if (pvt->fam == 0x17) { > + if (pvt->fam == 0x17 || pvt->fam == 0x18) { >

Re: [Xen-devel] [PATCH v2 01/17] x86/cpu: create Dhyana init file and register new cpu_dev to system

On 23/07/2018 15:20, Pu Wen wrote: > Add x86 architecture support for new processor Hygon Dhyana Family 18h. > Rework to create a separated file(arch/x86/kernel/cpu/hygon.c) from the > AMD init one(arch/x86/kernel/cpu/amd.c) to initialize Dhyana CPU. In > this way we can remove old AMD

Re: [Xen-devel] [RFC PATCH v4 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 28/02/2018 19:27, Maran Wilson wrote: > Sorry for the delay between this version and the last -- it was mostly > due to holidays and everyone being focused on security bug mitigation > issues. Here are the links to the previous email threads in case it is > helpful: > > V3:

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote: > +obj-$(CONFIG_XEN_PVH) += pvh.o > +obj-$(CONFIG_XEN_PVH) += pvh-head.o > + Probably a better place for these would be arch/x86/platform/pvh/{enlighten.c,head.S}. (Just because there are no .c or .S files in arch/x86). Maybe Xen ought to be

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

On 01/03/2018 07:11, Juergen Gross wrote: >> Probably a better place for these would be >> arch/x86/platform/pvh/{enlighten.c,head.S}. (Just because there are no >> .c or .S files in arch/x86). > Right. > >> Maybe Xen ought to be moved under >> arch/x86/platform too. > And hyperv and kvm, too?

Re: [Xen-devel] [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 01/03/2018 16:02, Boris Ostrovsky wrote: > On 02/28/2018 01:27 PM, Maran Wilson wrote: >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >> index eb7f43f23521..fa7cd0305125 100644 >> --- a/arch/x86/Kconfig >> +++ b/arch/x86/Kconfig >> @@ -791,6 +791,14 @@ config KVM_GUEST >>underlying

Re: [Xen-devel] [PATCH 01/12] checkpatch: Add xendevicemodel_handle to the list of types

mod, domid_t domid, ... > > CC: Eric Blake <ebl...@redhat.com> > CC: Paolo Bonzini <pbonz...@redhat.com> > CC: Daniel P. Berrange <berra...@redhat.com> > Signed-off-by: Ian Jackson <ian.jack...@eu.citrix.com> > --- > v6.1: New patch > --- > scripts/

Re: [Xen-devel] [RFC PATCH 13/30] pc/xen: Xen Q35 support: provide IRQ handling for PCI devices

On 12/03/2018 19:33, Alexey Gerasimenko wrote: > xen_pci_slot_get_pirq --> xen_cmn_pci_slot_get_pirq > xen_piix3_set_irq --> xen_cmn_set_irq Don't abbrvt names, xen_hvm_ is a better prefix. > > +fprintf(stderr, "WARNING: guest domain attempted to use > PIRQ%c " > +

Re: [Xen-devel] [PATCH v2 06/27] x86/entry/64: Adapt assembly for PIE support

On 14/03/2018 16:54, Christopher Lameter wrote: >>> + pushq %rax/* Support Position Independent Code */ >>> + leaq1f(%rip), %rax /* RIP */ >>> + xchgq %rax, (%rsp)/* Restore RAX, put 1f */ >>> iretq /* continues at repeat_nmi below */ >>>

Re: [Xen-devel] [PATCH v2] qemu: replace "" with <> in headers

On 21/03/2018 15:46, Michael S. Tsirkin wrote: > +if (m@^\s*#include\s+"qemu/@o) { > +s@^(\s*#include\s+)"qemu/([^"]+)"(.*)$@$1$3@o) { > +} else { > +s@^(\s*#include\s+)"([^"]+)"(.*)$@$1$3@o) { > +} Can you explain the changes in the source tree layout? Also, s{}{} and m{} are a bit more

Re: [Xen-devel] [PATCH v2] qemu: replace "" with <> in headers

On 21/03/2018 16:11, Michael S. Tsirkin wrote: >> Can you explain the changes in the source tree layout? > include/qemu -> include/qemu/common > include/* -> include/qemu/* Ok, then perhaps "util" instead of common would match the source layout more. Paolo > Thus one uses any qemu headers with

Re: [Xen-devel] [Qemu-devel] [PATCH] chardev: Convert IOReadHandler to read an unsigned number of bytes

On 11/10/2018 17:24, Philippe Mathieu-Daudé wrote: >> On the other hand, fd_chr_read_poll is not an IOCanReadHandler, and this >> patch therefore probably doesn't compile? > It does compile. > > fd_chr_update_read_handler() uses fd_chr_read_poll with io_add_watch_poll(): > > GSource

Re: [Xen-devel] [Qemu-devel] [PATCH] chardev: Convert IOReadHandler to read an unsigned number of bytes

On 11/10/2018 15:14, Philippe Mathieu-Daudé wrote: > The number of bytes can not be negative nor zero. > > Fixed 2 format string: > - hw/char/spapr_vty.c > - hw/usb/ccid-card-passthru.c > > Signed-off-by: Philippe Mathieu-Daudé > --- > See:

Re: [Xen-devel] [PATCH v7 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 17/04/18 01:09, Maran Wilson wrote: > For certain applications it is desirable to rapidly boot a KVM virtual > machine. In cases where legacy hardware and software support within the > guest is not needed, Qemu should be able to boot directly into the > uncompressed Linux kernel binary without

Re: [Xen-devel] [PATCH v5 03/24] hw: acpi: The RSDP build API can return void

On 05/11/2018 02:40, Samuel Ortiz wrote: > /* RSDP */ > -static GArray * > +static void > build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned xsdt_tbl_offset) > { > AcpiRsdpDescriptor *rsdp = acpi_data_push(rsdp_table, sizeof *rsdp); > @@ -392,8 +392,6 @@ build_rsdp(GArray

Re: [Xen-devel] [Qemu-devel] [PATCH v5 00/24] ACPI reorganization for hardware-reduced API addition

On 16/11/18 17:29, Igor Mammedov wrote: > General suggestions for this series: > 1. Preferably don't do multiple changes within a patch > neither post huge patches (unless it's pure code movement). > (it's easy to squash patches later it necessary) > 2. Start small, pick a table

Re: [Xen-devel] [PATCH v3 0/4] QEMU changes to do PVH boot

On 15/01/19 13:18, Liam Merwick wrote: > For certain applications it is desirable to rapidly boot a KVM virtual > machine. In cases where legacy hardware and software support within the > guest is not needed, QEMU should be able to boot directly into the > uncompressed Linux kernel binary with

Re: [Xen-devel] [PATCH v8 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 12/12/18 19:09, Maran Wilson wrote: > On 12/6/2018 1:21 PM, Paolo Bonzini wrote: >> On 06/12/18 07:02, Maran Wilson wrote: >>> For certain applications it is desirable to rapidly boot a KVM virtual >>> machine. In cases where legacy hardware and software s

Re: [Xen-devel] [PATCH v9 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 12/12/18 21:39, Borislav Petkov wrote: > On Tue, Dec 11, 2018 at 11:29:21AM -0800, Maran Wilson wrote: >> Is your question about what options you need to provide to Qemu? Or is your >> question about the SW implementation choices? >> >> Assuming the former... > Yeah, that's what I wanted to

[Xen-devel] [PATCH 2/2] avoid TABs in files that only contain a few

/check_ftag.c tests/tcg/cris/check_int64.c tests/tcg/cris/check_lz.c tests/tcg/cris/check_openpf5.c tests/tcg/cris/check_sigalrm.c tests/tcg/cris/crisutils.h tests/tcg/cris/sys.c tests/tcg/i386/test-i386-ssse3.c ui/vgafont.h Signed-off-by: Paolo Bonzini --- block

Re: [Xen-devel] [PATCH 2/2] avoid TABs in files that only contain a few

On 14/12/18 11:22, Daniel P. Berrangé wrote: >> crypto/aes.c >> crypto/desrfb.c > > I'd rather like this to be cleaned to finish the job for > crypto/. Ok, will do. Paolo ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 07/12/18 07:02, Juergen Gross wrote: > On 06/12/2018 23:11, Paolo Bonzini wrote: >> On 06/12/18 07:04, Maran Wilson wrote: >>> +config PVH >>> + bool "Support for running PVH guests" >>> + ---help--- >>> + This option

Re: [Xen-devel] [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 07/12/18 14:50, Juergen Gross wrote: > The PVH boot entry is in the same bzImage binary as the normal one. > Its just another entry, similar to the Xen PV boot entry. So the binary > arch/x86/boot/bzimage can be booted either on bare metal via grub2 or > other boot-loaders, as Xen PV-guest, as

Re: [Xen-devel] [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 07/12/18 14:58, Juergen Gross wrote: > On 07/12/2018 14:52, Paolo Bonzini wrote: >> On 07/12/18 14:50, Juergen Gross wrote: >>> The PVH boot entry is in the same bzImage binary as the normal one. >>> Its just another entry, similar to the Xen PV boot entry. So t

Re: [Xen-devel] [PATCH v8 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 06/12/18 07:02, Maran Wilson wrote: > For certain applications it is desirable to rapidly boot a KVM virtual > machine. In cases where legacy hardware and software support within the > guest is not needed, Qemu should be able to boot directly into the > uncompressed Linux kernel binary without

Re: [Xen-devel] [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 06/12/18 07:04, Maran Wilson wrote: > +config PVH > + bool "Support for running PVH guests" > + ---help--- > + This option enables the PVH entry point for guest virtual machines > + as specified in the x86/HVM direct boot ABI. > + IIUC this breaks "normal" bzImage boot, so

Re: [Xen-devel] [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 06/12/18 23:34, Boris Ostrovsky wrote: > On 12/6/18 5:11 PM, Paolo Bonzini wrote: >> On 06/12/18 07:04, Maran Wilson wrote: >>> +config PVH >>> + bool "Support for running PVH guests" >>> + ---help--- >>> + This option

Re: [Xen-devel] [PATCH v8 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 06/12/18 22:58, Boris Ostrovsky wrote: > On 12/6/18 4:37 PM, Borislav Petkov wrote: >> On Thu, Dec 06, 2018 at 10:21:12PM +0100, Paolo Bonzini wrote: >>> Thanks! I should be able to post a Tested-by next Monday. Boris, are >>> you going to pick it up for 4

Re: [Xen-devel] [PATCH v8 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 06/12/18 07:06, Maran Wilson wrote: > +config KVM_GUEST_PVH > + bool "Support for running as a KVM PVH guest" > + depends on KVM_GUEST > + select PVH > + ---help--- > + This option enables starting KVM guests via the PVH entry point as > + specified in the x86/HVM

Re: [Xen-devel] [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 07/12/18 00:11, Boris Ostrovsky wrote: > On 12/6/18 5:49 PM, Paolo Bonzini wrote: >> On 06/12/18 23:34, Boris Ostrovsky wrote: >>> On 12/6/18 5:11 PM, Paolo Bonzini wrote: >>> >>>> and also >>>> >>>>depends on !EFI >>&

Re: [Xen-devel] [Qemu-devel] [PATCH v5 00/24] ACPI reorganization for hardware-reduced API addition

On 20/11/18 13:57, Igor Mammedov wrote: > On Mon, 19 Nov 2018 18:14:26 +0100 > Paolo Bonzini wrote: > >> On 19/11/18 16:31, Igor Mammedov wrote: >>> I've tried to give suggestions how to restructure series >>> on per patch basis. In my opinion it quite possib

Re: [Xen-devel] [Qemu-devel] [PATCH v5 00/24] ACPI reorganization for hardware-reduced API addition

On 19/11/18 19:14, Michael S. Tsirkin wrote: > On Mon, Nov 19, 2018 at 06:14:26PM +0100, Paolo Bonzini wrote: >> On 19/11/18 16:31, Igor Mammedov wrote: >>> I've tried to give suggestions how to restructure series >>> on per patch basis. In my opinion it quite p

Re: [Xen-devel] [Qemu-devel] [PATCH v5 00/24] ACPI reorganization for hardware-reduced API addition

On 19/11/18 16:31, Igor Mammedov wrote: > I've tried to give suggestions how to restructure series > on per patch basis. In my opinion it quite possible to split > series in several smaller ones and it should really help with > making series cleaner and easier/faster to review/amend/merge > vs

Re: [Xen-devel] [PATCH v7 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 16/11/18 18:17, Maran Wilson wrote: > On 11/16/2018 2:46 AM, Paolo Bonzini wrote: >> On 17/04/18 01:09, Maran Wilson wrote: >>> For certain applications it is desirable to rapidly boot a KVM virtual >>> machine. In cases where legacy hardware and software s

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

On 21/02/19 12:45, Joao Martins wrote: > On 2/20/19 9:09 PM, Paolo Bonzini wrote: >> On 20/02/19 21:15, Joao Martins wrote: >>> 2. PV Driver support (patches 17 - 39) >>> >>> We start by redirecting hypercalls from the backend to routines >>> which

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

On 20/02/19 21:15, Joao Martins wrote: > 2. PV Driver support (patches 17 - 39) > > We start by redirecting hypercalls from the backend to routines > which emulate the behaviour that PV backends expect i.e. grant > table and interdomain events. Next, we add support for late > initialization

Re: [Xen-devel] [PATCH 1/6] xen: Introduce -xen-stubdom option

On 11/03/19 19:02, Jason Andryuk wrote: > With Xen, QEMU can run isolated in a dedicated service VM - a stubdom. > There are a few differences when running in a stubdom compared to dom0. > Add the -xen-stubdom option to select this mode at runtime. The default > is off. This should be "-accel

Re: [Xen-devel] [RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently

On 27/05/19 14:32, Peter Zijlstra wrote: > On Mon, May 27, 2019 at 12:21:59PM +0200, Paolo Bonzini wrote: >> On 27/05/19 11:47, Peter Zijlstra wrote: > >>> --- a/arch/x86/kernel/kvm.c >>> +++ b/arch/x86/kernel/kvm.c >>> @@ -580,7 +580,7 @@ s

Re: [Xen-devel] [RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently

On 27/05/19 11:47, Peter Zijlstra wrote: > On Sat, May 25, 2019 at 10:54:50AM +0200, Juergen Gross wrote: >> On 25/05/2019 10:22, Nadav Amit wrote: > >>> diff --git a/arch/x86/include/asm/paravirt_types.h >>> b/arch/x86/include/asm/paravirt_types.h >>> index 946f8f1f1efc..3a156e63c57d 100644 >>>

Re: [Xen-devel] [qemu-s390x] [Qemu-devel] [PATCH v7 33/42] exec: Replace device_endian with MemOp

On 16/08/19 12:12, Thomas Huth wrote: > This patch is *huge*, more than 800kB. It keeps being stuck in the the > filter of the qemu-s390x list each time you send it. Please: > > 1) Try to break it up in more digestible pieces, e.g. change only one > subsystem at a time (this is also better

Re: [Xen-devel] [Qemu-devel] [PATCH v7 25/42] hw/misc: Declare device little or big endian

On 16/08/19 12:04, Philippe Mathieu-Daudé wrote: >> diff --git a/hw/misc/a9scu.c b/hw/misc/a9scu.c >> index 4307f00..3de8cd3 100644 >> --- a/hw/misc/a9scu.c >> +++ b/hw/misc/a9scu.c >> @@ -94,7 +94,7 @@ static void a9_scu_write(void *opaque, hwaddr offset, >>  static const MemoryRegionOps

Re: [Xen-devel] [qemu-s390x] [Qemu-devel] [PATCH v7 33/42] exec: Replace device_endian with MemOp

On 19/08/19 20:28, Paolo Bonzini wrote: > On 16/08/19 12:12, Thomas Huth wrote: >> This patch is *huge*, more than 800kB. It keeps being stuck in the the >> filter of the qemu-s390x list each time you send it. Please: >> >> 1) Try to break it up in more digestible p

Re: [Xen-devel] [Qemu-devel] [PATCH v6 19/26] exec: Delete DEVICE_HOST_ENDIAN

On 07/08/19 10:32, tony.ngu...@bt.com wrote: > +#if defined(HOST_WORDS_BIGENDIAN) > +    .endianness = MO_BE, > +#else > +    .endianness = MO_LE, > +#endif Host endianness is just 0, isn't it? Paolo ___ Xen-devel mailing list

Re: [Xen-devel] [Qemu-devel] [PATCH v6 15/26] build: Correct non-common common-obj-* to obj-*

On 07/08/19 10:31, tony.ngu...@bt.com wrote: > Preparation for replacing device_endian with MemOp. > > Device realizing code with MemorRegionOps endianness as > DEVICE_NATIVE_ENDIAN is not common code. > > Corrected devices were identified by making the declaration of > DEVICE_NATIVE_ENDIAN

Re: [Xen-devel] [Qemu-devel] [PATCH v6 20/26] memory: Access MemoryRegion with endianness

On 07/08/19 10:33, tony.ngu...@bt.com wrote: > +#ifdef NEED_CPU_H > +    return ctz32(size) | MO_TE; > +#else >      return ctz32(size); > +#endif Please use two separate functions for this, for example size_to_memop and target_size_to_memop, or even just add MO_TE to the callers that need it

Re: [Xen-devel] [Qemu-devel] [PATCH v6 20/26] memory: Access MemoryRegion with endianness

On 07/08/19 19:49, Richard Henderson wrote: > On 8/7/19 1:33 AM, tony.ngu...@bt.com wrote: >> @@ -551,6 +551,7 @@ void virtio_address_space_write(VirtIOPCIProxy *proxy, >> hwaddr addr, >> /* As length is under guest control, handle illegal values. */ >> return; >> } >> +

Re: [Xen-devel] [PATCH-for-5.0 v3 6/6] hw/pci-host: Add Kconfig entry to select the IGD Passthrough Host Bridge

On 09/12/19 10:50, Philippe Mathieu-Daudé wrote: > Add the XEN_IGD_PASSTHROUGH Kconfig option. > > Xen build has that option selected by default. Non-Xen builds now > have to select this feature manually. > > Signed-off-by: Philippe Mathieu-Daudé > --- > v3: Only default with Xen (Alex

Re: [Xen-devel] [PATCH-for-5.0 v3 6/6] hw/pci-host: Add Kconfig entry to select the IGD Passthrough Host Bridge

On 09/12/19 11:10, Durrant, Paul wrote: >> >> Signed-off-by: Philippe Mathieu-Daudé >> --- >> v3: Only default with Xen (Alex Williamson) >> >> I did not used 'depends on XEN' as suggested by Alex but >> 'default y if XEN', so one can build XEN without this feature >> (for example, on other ARCH

Re: [Xen-devel] [PATCH-for-5.0 v3 6/6] hw/pci-host: Add Kconfig entry to select the IGD Passthrough Host Bridge

On 09/12/19 11:56, Philippe Mathieu-Daudé wrote: > > I think so, but with PC_I440FX -> PCI_I440FX ;) > > It would be cleaner to pass the CONFIG_XEN_PCI_PASSTHROUGH variable to > Kconfig and use it (use 'depends on XEN_PCI_PASSTHROUGH'). > > This can be another step, so if this series looks OK

Re: [Xen-devel] [PATCH 04/12] hw/i386/pc: Remove obsolete cpu_set_smm_t typedef

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é > --- >

Re: [Xen-devel] [PATCH 03/12] hw/i386/pc: Remove obsolete pc_pci_device_init() declaration

On 13/12/19 17:17, Philippe Mathieu-Daudé wrote: > In commit 1454509726 we removed the pc_pci_device_init() > deprecated function and its calls, but we forgot to remove > its prototype. Do that now. > > Signed-off-by: Philippe Mathieu-Daudé > --- > include/hw/i386/pc.h | 1 - > 1 file changed,

Re: [Xen-devel] [PATCH 06/12] hw/i386/ich9: Move unnecessary "pci_bridge.h" include

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é > --- >

Re: [Xen-devel] [PATCH 09/12] hw/intc/ioapic: Make ioapic_print_redtbl() static

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é > --- >

Re: [Xen-devel] [PATCH 07/12] hw/ide/piix: Remove superfluous DEVICE() cast

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

Re: [Xen-devel] [PATCH 05/12] hw/i386/ich9: Remove unused include

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é > --- >

Re: [Xen-devel] [PATCH 12/12] hw/i386/pc: Move PC-machine specific declarations to 'pc_internal.h'

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.

Re: [Xen-devel] [PATCH 13/16] xen: convert "-machine igd-passthru" to an accelerator property

On 14/11/19 10:39, Paul Durrant wrote: > On Wed, 13 Nov 2019 at 14:53, Paolo Bonzini wrote: >> >> The first machine property to fall is Xen's Intel integrated graphics >> passthrough. The "-machine igd-passthru" option does not set anymore >> a propert

Re: [Xen-devel] [PATCH-for-5.0 v3 3/6] hw/pci-host/i440fx: Use size_t to iterate over ARRAY_SIZE()

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

Re: [Xen-devel] [PATCH 1/2] misc: Replace zero-length arrays with flexible array member (automatic)

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

Re: [Xen-devel] [PATCH 1/2] misc: Replace zero-length arrays with flexible array member (automatic)

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; >  

Re: [Xen-devel] [PATCH 0/2] misc: Replace zero-length arrays with flexible array member

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

Re: [Xen-devel] [PATCH 00/20] hw: Clean up hw/i386 headers (and few alpha/hppa)

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" >>>

Re: [Xen-devel] [PATCH v3 03/20] exec: Let qemu_ram_*() functions take a const pointer argument

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

Re: [Xen-devel] [PATCH] Avoid cpu_physical_memory_rw() with a constant is_write argument

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

Re: [PATCH v3 0/3] various: Remove unnecessary casts

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

Re: [PATCH v2 0/3] Add Xen CpusAccel

pus.c => dummy-cpus.c} (71%) > delete mode 100644 accel/qtest/qtest-cpus.h > Acked-by: Paolo Bonzini

Re: [PATCH 0/5] qapi: Restrict machine (and migration) specific commands

Can do 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

Re: [PATCH] qemu/atomic.h: prefix qemu_ to solve collisions

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

Re: [PATCH] qemu/atomic.h: prefix qemu_ to solve collisions

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

Re: [PATCH v2 0/6] hw/xen: Housekeeping

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

Re: [PATCH v2] qemu/atomic.h: prefix qemu_ to solve collisions

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

Re: [PATCH v3] qemu/atomic.h: rename atomic_ to qatomic_

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 >> --- >>

Re: [PATCH v3 0/3] various: Remove unnecessary casts

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

Re: [PATCH v3] accel: Move Xen accelerator code under accel/xen/

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 >

Re: [PATCH-for-5.2] hw/i386/q35: Remove unreachable Xen code on Q35 machine

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

Re: [PATCH v2 0/3] Add Xen CpusAccel

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: >>>>

Re: [PATCH 24/26] hw/usb/usb-hcd: Use UHCI type definitions

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, "

Re: [PATCH] xen: Actually fix build without passthrough

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

Re: [PATCH v4] xen: fix build without pci passthrough

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.

Re: [RFC PATCH 14/35] hw/i386/pc: Emit warning when old code is used

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 >

Re: [RFC PATCH 17/35] hw/input/pckbd: Emit warning when old code is used

t;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_function_us

Re: [RFC PATCH 06/35] hw/timer/arm_timer: Emit warning when old code is used

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

Re: [RFC PATCH 32/35] hw/riscv: Emit warning when old code is used

q irq) > { > SiFiveUARTState *s = g_malloc0(sizeof(SiFiveUARTState)); > + > +qdev_warn_deprecated_function_used(); > + > s->irq = irq; > qemu_chr_fe_init(>chr, chr, _abort); > qemu_chr_fe_set_handlers(>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

Re: [RFC PATCH 29/35] hw/ppc/ppc_booke: Emit warning when old code is used

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 >

Re: [RFC PATCH 27/35] hw/ppc/ppc: Emit warning when old code is used

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 >

Re: [RFC PATCH 33/35] hw/timer/slavio_timer: Emit warning when old code is used

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

Re: [RFC PATCH 21/35] hw/lm32/lm32_hwsetup: Emit warning when old code is used

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

Re: [RFC PATCH 20/35] hw/intc/i8259: Emit warning when old code is used

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

Re: [RFC PATCH 26/35] hw/openrisc/cputimer: Emit warning when old code is used

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

Re: [RFC PATCH 30/35] hw/ppc/virtex_ml507: Emit warning when old code is used

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

  1   2   >