On 28/11/2017 20:34, 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
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
> be
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 enlighte
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 that
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
>
> W
On 30/11/2017 19:23, Maran Wilson wrote:
> Are you saying the Linux PVH entry code (such as init_pvh_bootparams())
> should use the fw_cfg interface to read the e820 memory map data and put
> it into the zeropage? Basically, keeping the patch very much like it
> already is, just extracting the e820
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
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 ++
+
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 arch/x86/pvh-h
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
>>>
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
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 mini
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
Xen-devel@lists.xenprojec
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 (onl
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 condi
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;
>> }
>> +
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 a9_scu_op
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 reviewa
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
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 o
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
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 xen
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 Williamso
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 t
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 to
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, 1
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/
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:
> 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:
> 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:
> 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:
> 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 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 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 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
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 t
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 dir
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 w
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
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 enables the
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
>>>
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 enables the
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 X
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
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 support
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 know
/cris/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
---
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
https://lists.
PACE_SIZE when Xen gains the ability to
> emulate MCFG table accesses.
>
> Signed-off-by: Paul Durrant
> --
> Cc: Stefano Stabellini
> Cc: Anthony Perard
> Cc: "Michael S. Tsirkin"
> Cc: Marcel Apfelbaum
> Cc: Paolo Bonzini
> Cc: Richard Henderson
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 configur
mod, domid_t domid, ...
>
> CC: Eric Blake
> CC: Paolo Bonzini
> CC: Daniel P. Berrange
> Signed-off-by: Ian Jackson
> ---
> v6.1: New patch
> ---
> scripts/checkpatch.pl | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts
e object is not a file; and print the errno
> value in the error message.
>
> Signed-off-by: Ian Jackson
> CC: Thomas Huth
> CC: Paolo Bonzini
> CC: Stefano Stabellini
> CC: Anthony PERARD
> ---
> v6: New patch in this version of the series
> ---
> scripts/get
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 "
> +
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 */
>>> UNW
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
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
>
On 22/03/2018 20:29, Michael S. Tsirkin wrote:
> On Wed, Mar 21, 2018 at 05:22:03PM +0100, Kevin Wolf wrote:
>>> It's all still very much a non-standard convention and so less robust
>>> than prefixing file name with a project-specifix prefix.
>> I've always had the impression that it's by far the
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 architecture
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) {
> __f17h_set_
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.
>
> https://lkml.org/lkml/2018/4/16/100
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: https://lists.gnu.org/archive/html/qemu-devel/2018-10/m
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 *io_add_watch
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 move
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: https://lkml.org/lkm
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?
A
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
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 *rsdp_tab
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 t
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 gener
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 what
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 support
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 p
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
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 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/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 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 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 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
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
pus.c => dummy-cpus.c} (71%)
> delete mode 100644 accel/qtest/qtest-cpus.h
>
Acked-by: Paolo Bonzini
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 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 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 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 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 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 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 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 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
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 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 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 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 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
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
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
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.
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 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
1 - 100 of 165 matches
Mail list logo
