Re: [Xen-devel] [PATCH hmm 08/15] xen/gntdev: Use select for DMA_SHARED_BUFFER
On 15.10.19 20:12, Jason Gunthorpe wrote:
From: Jason Gunthorpe
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are turned on implicitly when the user enables a kconfig
that needs them.
Otherwise the XEN_GNTDEV_DMABUF kconfig is overly difficult to enable.
Fixes: 932d6562179e ("xen/gntdev: Add initial support for dma-buf UAPI")
Cc: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: xen-devel@lists.xenproject.org
Cc: Juergen Gross
Cc: Stefano Stabellini
Signed-off-by: Jason Gunthorpe
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 22/34] xen: Use CONFIG_PREEMPTION
On 15.10.19 21:18, Sebastian Andrzej Siewior wrote: From: Thomas Gleixner CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT. Both PREEMPT and PREEMPT_RT require the same functionality which today depends on CONFIG_PREEMPT. Switch the preempt anand xen-ops code over to use CONFIG_PREEMPTION. Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Stefano Stabellini Cc: xen-devel@lists.xenproject.org Signed-off-by: Thomas Gleixner Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
On 15.10.19 20:18, Julien Grall wrote: virt_to_maddr() is using the hardware page-table walk instructions to translate a virtual address to physical address. The function should only be called on virtual address mapped. _end points past the end of Xen binary and may not be mapped when the binary size is page-aligned. This means virt_to_maddr() will not be able to do the translation and therefore crash Xen. Note there is also an off-by-one issue in this code, but the panic will trump that. Both issues can be fixed by using _end - 1 in the check. Signed-off-by: Julien Grall With or without the cast suggested by Stefano: Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/arm: domain_build: Print the correct domain in dtb_load()
On 15.10.19 18:45, Julien Grall wrote: Hi Juergen, Gentle ping. Cheers, On 10/10/19 3:43 PM, Julien Grall wrote: Hi, Hmm, it looks like I forgot this patch before the freeze. Juergen, are you happy with this to go in Xen 4.13? Cheers, On 15/08/2019 18:29, Julien Grall wrote: dtb_load() can be called by other domain than dom0. To avoid confusion in the log, print the correct domain. Signed-off-by: Julien Grall Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] libxl_pci: Fix guest shutdown with PCI PT attached
On Tue, Oct 15, 2019 at 06:59:37PM +0200, Sander Eikelenboom wrote: >On 14/10/2019 17:03, Chao Gao wrote: >> On Thu, Oct 10, 2019 at 06:13:43PM +0200, Sander Eikelenboom wrote: >>> On 01/10/2019 12:35, Anthony PERARD wrote: Rewrite of the commit message: Before the problematic commit, libxl used to ignore error when destroying (force == true) a passthrough device, especially error that happens when dealing with the DM. Since fae4880c45fe, if the DM failed to detach the pci device within the allowed time, the timed out error raised skip part of pci_remove_*, but also raise the error up to the caller of libxl__device_pci_destroy_all, libxl__destroy_domid, and thus the destruction of the domain fails. In this patch, if the DM didn't confirmed that the device is removed, we will print a warning and keep going if force=true. The patch reorder the functions so that pci_remove_timeout() calls pci_remove_detatched() like it's done when DM calls are successful. We also clean the QMP states and associated timeouts earlier, as soon as they are not needed anymore. Reported-by: Sander Eikelenboom Fixes: fae4880c45fe015e567afa223f78bf17a6d98e1b Signed-off-by: Anthony PERARD >>> >>> Hi Anthony / Chao, >>> >>> I have to come back to this, a bit because perhaps there is an underlying >>> issue. >>> While it earlier occurred to me that the VM to which I passed through most >>> pci-devices >>> (8 to be exact) became very slow to shutdown, but I didn't investigate it >>> further. >>> >>> But after you commit messages from this patch it kept nagging, so today I >>> did some testing >>> and bisecting. >>> >>> The difference in tear-down time at least from what the IOMMU code logs is >>> quite large: >>> >>> xen-4.12.0 >>> Setup: 7.452 s >>> Tear-down: 7.626 s >>> >>> xen-unstable-ee7170822f1fc209f33feb47b268bab35541351d >>> Setup: 7.468 s >>> Tear-down: 50.239 s >>> >>> Bisection turned up: >>> commit c4b1ef0f89aa6a74faa4618ce3efed1de246ec40 >>> Author: Chao Gao >>> Date: Fri Jul 19 10:24:08 2019 +0100 >>> libxl_qmp: wait for completion of device removal >>> >>> Which makes me wonder if there is something going wrong in Qemu ? > >> Hi Sander, >Hi Chao, > >> >> Thanks for your testing and the bisection. >> >> I tried on my machine, the destruction time of a guest with 8 pass-thru >> devices increased from 4s to 12s after applied the commit above. > >To what patch are you referring Anthony's or >c4b1ef0f89aa6a74faa4618ce3efed1de246ec40 ? The latter. > >> In my understanding, I guess you might get the error message "timed out >> waiting for DM to remove...". There might be some issues on your assigned >> devices' drivers. You can first unbind the devices with their drivers in >> VM and then tear down the VM, and check whether the VM teardown gets >> much faster. > >I get that error message when I test with Anthony's patch applied, the >destruction time with that patch is low. > >How ever my point was if that patch is correct in the sense that there seems >to be an underlying issue >which causes it to take so long. That issue was uncovered by >c4b1ef0f89aa6a74faa4618ce3efed1de246ec40, so I'm not >saying that commit is wrong in any sense, it just uncovered another issue that >was already present, >but hard to detect as we just didn't wait at destruction time (and thus the >same effect as a timeout). Actually, it is introduced by c4b1ef0f89, though it did fix another issue. > >One or the other way that was just a minor issue until >fae4880c45fe015e567afa223f78bf17a6d98e1b, where the long >destruction time now caused the domain destruction to stall, which was then >fixed by Antony's patch, but that uses >a timeout which kinds of circumvents the issue, instead of finding out where >is comes from and solve it there ( >if that is possible of course). > >And I wonder if Anthony's patch doesn't interfere with the case you made >c4b1ef0f89aa6a74faa4618ce3efed1de246ec40 for, >if you get the timeout error message as well, then that is kind of not waiting >for the destruction to finish, isn't it ? > >Chao, >could you perhaps test for me Xen with as latest commit >ee7170822f1fc209f33feb47b268bab35541351d ? >That is before Anthony's patch series, but after your >c4b1ef0f89aa6a74faa4618ce3efed1de246ec40. It's actually what I did. VM teardown with 8 pass-thru devices on my side takes 12s which only took 4s without my patch. Thanks Chao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
On Tue, 15 Oct 2019, Julien Grall wrote: > On 15/10/2019 21:38, Stefano Stabellini wrote: > > On Tue, 15 Oct 2019, Julien Grall wrote: > >> Hi, > >> > >> On 15/10/2019 20:28, Stefano Stabellini wrote: > >>> On Tue, 15 Oct 2019, Julien Grall wrote: > virt_to_maddr() is using the hardware page-table walk instructions to > translate a virtual address to physical address. The function should > only be called on virtual address mapped. > > _end points past the end of Xen binary and may not be mapped when the > binary size is page-aligned. This means virt_to_maddr() will not be able > to do the translation and therefore crash Xen. > > Note there is also an off-by-one issue in this code, but the panic will > trump that. > > Both issues can be fixed by using _end - 1 in the check. > > Signed-off-by: Julien Grall > > --- > > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Julien Grall > Cc: Konrad Rzeszutek Wilk > Cc: Stefano Stabellini > Cc: Tim Deegan > Cc: Wei Liu > Cc: jgr...@suse.com > > x86 seems to be affected by the off-by-one issue. Jan, Andrew? > > This could be reached by a domain via XEN_SYSCTL_page_offline_op. > However, the operation is not security supported (see XSA-77). So we are > fine here. > --- > xen/include/asm-arm/mm.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h > index 262d92f18d..174acd8859 100644 > --- a/xen/include/asm-arm/mm.h > +++ b/xen/include/asm-arm/mm.h > @@ -153,7 +153,7 @@ extern unsigned long xenheap_base_pdx; > > #define is_xen_fixed_mfn(mfn) \ > ((mfn_to_maddr(mfn) >= virt_to_maddr(&_start)) && \ > - (mfn_to_maddr(mfn) <= virt_to_maddr(&_end))) > + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1))) > >>> > >>> Thank you for sending the patch and I think that "_end - 1" is the right > >>> fix. I am just wondering whether we want/need an explicit cast of some > >>> sort here, because technically _end is a char[] and 1 is a integer. > >>> Maybe: > >>> > >>> ((vaddr_t)_end - 1) > >>> > >>> ? > >> > >> I vaguely remember a lengthy discussion about it last year. But I don't > >> think there was any conclusion in it. > >> > >> In this case, what are you trying to prevent with the cast? Is it > >> underflow of an array? If so, how the cast is actually going to prevent > >> the compiler to do the wrong thing? > > > > Yes, there was a long discussion at the beginning of the year; it was > > about how to define _start and _end so that we could avoid compilers > > undefined behavior. The main underlying issue is that comparisons > > between pointers to different objects are undefined [1] (_start and _end > > can be interpreted as pointers to different objects). > > > > This case is a bit different, and easier. The issue is that, because the > > result of "_end - 1" is not within the boundaries of the _end array, > > then the operation is "undefined" by the C specification (C99 6.5.6). > > Undefined is not good. > > > > So, I am not really asking for any complex fix, or hypervisor-wide > > rework. I am only asking to avoid introducing new undefined behavior. > > Casting to vaddr_t should solve it I think. > > I agree that we should not add more undefined behavior in Xen. However, > I don't like cast if they can't be justified. > > In this particular case, you seem to be unsure this is going to remove > an undefined behavior. IIRC, I pointed out in the past that compiler can > see through cast. > > So can we have some certainty that your suggestion is going to work? My suggestion is going to work: "the compiler sees through casts" referred to comparisons between pointers, where we temporarily casted both pointers to integers and back to pointers via a MACRO. That case was iffy because the MACRO was clearly a workaround the spec. Here the situation is different. For one, we are doing arithmetic. Also virt_to_maddr already takes a vaddr_t as argument. So instead of doing pointers arithmetic, then converting to vaddr_t, we are converting to vaddr_t first, then doing arithmetics, which is fine both from a C99 point of view and even a MISRA C point of view. I can't see a problem with that. I am sure as I reasonable can be :-) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 00/32] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge
Patchew URL: https://patchew.org/QEMU/20191015162705.28087-1-phi...@redhat.com/ Hi, This series seems to have some coding style problems. See output below for more information: Subject: [PATCH 00/32] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge Type: series Message-id: 20191015162705.28087-1-phi...@redhat.com === TEST SCRIPT BEGIN === #!/bin/bash git rev-parse base > /dev/null || exit 0 git config --local diff.renamelimit 0 git config --local diff.renames True git config --local diff.algorithm histogram ./scripts/checkpatch.pl --mailback base.. === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 Switched to a new branch 'test' e28fc07 hw/pci-host/i440fx: Remove the last PIIX3 traces 4278fc5 hw/pci-host: Rename incorrectly named 'piix' as 'i440fx' b5bb11c hw/pci-host/piix: Extract PIIX3 functions to hw/isa/piix3.c 256b64d hw/pci-host/piix: Fix code style issues e2e38d8 hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.h ec3e0e7 hw/pci-host/piix: Define and use the PIIX IRQ Route Control Registers 7da0dc4 hw/pci-host/piix: Move RCR_IOPORT register definition de2f83b hw/pci-host/piix: Extract piix3_create() 1f33a16 hw/i386/pc: Remove kvm_i386.h include 120bf64 hw/i386/pc: Extract pc_i8259_create() 7f4aed6 hw/i386/pc: Move gsi_state creation code af0863c hw/i386/pc: Reduce gsi_handler scope a3f9ad9 hw/i386/pc: Extract pc_gsi_create() 933d1cd hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c 223c701 hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create() 3db0574 hw/mips/mips_malta: Create IDE hard drive array dynamically 59225b9 piix4: add a mc146818rtc controller as specified in datasheet da01d59 piix4: add a i8254 pit controller as specified in datasheet 40518db piix4: add a i8257 dma controller as specified in datasheet 015de71 piix4: convert reset function to QOM 3a68c8f piix4: rename PIIX4 object to piix4-isa da51c52 Revert "irq: introduce qemu_irq_proxy()" 8cdeacf piix4: add a i8259 interrupt controller as specified in datasheet ecc92c2 piix4: add Reset Control Register c2cd556 piix4: rename some variables in realize function 67d9be5 MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets 0567e9d mc146818rtc: always register rtc to rtc list 3d9897a mc146818rtc: Include "mc146818rtc_regs.h" directly in mc146818rtc.c 4c0fde0 mc146818rtc: Move RTC_ISA_IRQ definition 1a8427e mc146818rtc: move structure to header file 0e65956 hw/i386/pc: Move kvm_i8259_init() declaration to sysemu/kvm.h 0201c90 hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers === OUTPUT BEGIN === 1/32 Checking commit 0201c90e8aaf (hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers) 2/32 Checking commit 0e659563bbd2 (hw/i386/pc: Move kvm_i8259_init() declaration to sysemu/kvm.h) 3/32 Checking commit 1a8427ecaa92 (mc146818rtc: move structure to header file) 4/32 Checking commit 4c0fde00c150 (mc146818rtc: Move RTC_ISA_IRQ definition) 5/32 Checking commit 3d9897ae2cf0 (mc146818rtc: Include "mc146818rtc_regs.h" directly in mc146818rtc.c) 6/32 Checking commit 0567e9df0795 (mc146818rtc: always register rtc to rtc list) 7/32 Checking commit 67d9be561c0c (MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets) 8/32 Checking commit c2cd5561adf9 (piix4: rename some variables in realize function) 9/32 Checking commit ecc92c2678b0 (piix4: add Reset Control Register) 10/32 Checking commit 8cdeacff34b5 (piix4: add a i8259 interrupt controller as specified in datasheet) 11/32 Checking commit da51c5247d1f (Revert "irq: introduce qemu_irq_proxy()") 12/32 Checking commit 3a68c8f5ff30 (piix4: rename PIIX4 object to piix4-isa) 13/32 Checking commit 015de71b6e75 (piix4: convert reset function to QOM) 14/32 Checking commit 40518dbbdc82 (piix4: add a i8257 dma controller as specified in datasheet) 15/32 Checking commit da01d594d8dd (piix4: add a i8254 pit controller as specified in datasheet) 16/32 Checking commit 59225b98d0d6 (piix4: add a mc146818rtc controller as specified in datasheet) WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? #192: deleted file mode 100644 total: 0 errors, 1 warnings, 166 lines checked Patch 16/32 has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. 17/32 Checking commit 3db0574cf65a (hw/mips/mips_malta: Create IDE hard drive array dynamically) 18/32 Checking commit 223c701490d0 (hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create()) 19/32 Checking commit 933d1cdd6cf9 (hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c) 20/32 Checking commit a3f9ad9887ff (hw/i386/pc: Extract pc_gsi_create()) 21/32 Checking commit af0863c35ccb (hw/i386/pc: Reduce gsi_handler scope) 22/32 Checking commit 7f4aed6122ba (hw/i386/pc: Move gsi_state creation code) 23/32 Checking commit 120bf64ae89c (hw/i386/pc: Extract pc_i8259_create()) 24/32 Checking commit 1f33a16f966e (hw/i386/pc: Remove
Re: [Xen-devel] [PATCH 0/2] xen/netback: bug fix and cleanup
From: Juergen Gross Date: Mon, 14 Oct 2019 11:09:08 +0200 > One bugfix (patch 1) I stumbled over while doing a cleanup (patch 2) > of the xen-netback init/deinit code. Please do not mix cleanups and genuine bug fixes. Submit the bug fix targetting the 'net' GIT tree, and once that eventually gets merged into 'net-next' you can submit the cleanup against that. Thanks. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/2] xen/efi: optionally call SetVirtualAddressMap()
On 12/10/2019 23:11, Marek Marczykowski-Górecki wrote:
> Some UEFI implementations are not happy about running in 1:1 addressing,
> but really virtual address space. Specifically, some access
> EfiBootServices{Code,Data}, or even totally unmapped areas. Example
> crash of GetVariable() call on Thinkpad W540:
>
> Xen call trace:
>[<0080>] 0080
>[<8c2b0398edaa>] 8c2b0398edaa
>
> Pagetable walk from 858483a1:
>L4[0x1ff] =
>
>
> Panic on CPU 0:
> FATAL PAGE FAULT
> [error_code=0002]
> Faulting linear address: 858483a1
>
>
> Fix this by calling SetVirtualAddressMap() runtime service, giving it
> 1:1 map for areas marked as needed during runtime. The address space in
> which EFI runtime services are called is unchanged, but UEFI view of it
> may be.
> SetVirtualAddressMap() can be called only once, so it might make
> future kexec EFI plumbing more complex or incompatible with this option.
There is no such thing as "future incompatibilities". There is "one
more piece of plumbing someone in the future needs to do with passing
EFI details".
Given how the rest of this looks, I'd just drop all references to
Kexec. I think what is here is misleading at best.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [BUG] Invalid guest state in Xen master, dom0 linux-5.3.6, domU windows 10
On 15/10/2019 22:35, Håkon Alstadheim wrote: > Got this just now, as my windows domU died: > > (XEN) [2019-10-15 21:23:44] d7v0 vmentry failure (reason 0x8021): > Invalid guest state (0) > (XEN) [2019-10-15 21:23:44] * VMCS Area ** > (XEN) [2019-10-15 21:23:44] *** Guest State *** > (XEN) [2019-10-15 21:23:44] CR0: actual=0x80050031, > shadow=0x80050031, gh_mask= > (XEN) [2019-10-15 21:23:44] CR4: actual=0x00172678, > shadow=0x00170678, gh_mask=ffe8f860 > (XEN) [2019-10-15 21:23:44] CR3 = 0x001aa002 > (XEN) [2019-10-15 21:23:44] RSP = 0x908e440fae68 > (0x908e440fae68) RIP = 0x9581e15d560b (0x9581e15d560b) > (XEN) [2019-10-15 21:23:44] RFLAGS=0x0197 (0x0197) DR7 = > 0x0400 > (XEN) [2019-10-15 21:23:44] Sysenter RSP= > CS:RIP=: > (XEN) [2019-10-15 21:23:44] sel attr limit base > (XEN) [2019-10-15 21:23:56] printk: 52 messages suppressed. > (XEN) [2019-10-15 21:23:56] [VT-D]d7:PCIe: unmap :81:00.0 > (XEN) [2019-10-15 21:23:56] [VT-D]d0:PCIe: map :81:00.0 > (XEN) [2019-10-15 21:23:59] printk: 2 messages suppressed. > (XEN) [2019-10-15 21:23:59] [VT-D]d7:PCIe: unmap :02:00.0 Sadly there is a large quantity of information missing here. > > xen_commandline : xen.cfg xen-marker-215 > console_timestamps=date iommu=1,intpost,verbose,debug > iommu_inclusive_mapping=1 com1=57600,8n1 com2=57600,8n1 > console=vga,com2 dom0_max_vcpus=8 dom0_mem=8G,max:8G > cpufreq=xen:performance,verbose smt=0 maxcpus=12 > core_parking=performance nmi=dom0 gnttab_max_frames=256 > gnttab_max_maptrack_frames=1024 vcpu_migration_delay=2000 > tickle_one_idle_cpu=1 spec-ctrl=no-xen sched=credit2 max_cstate=2 > clocksource=tsc tsc=stable:socket timer_slop=5000 loglvl=none/warning > guest_loglvl=none/warning ... and this would be why. Can you drop the "verbose,debug" from iommu=, and the loglvl=/guest_loglvl= on the end, and reproduce the problem again? That way, we should get the full VMCS Area dump, and I might be able to identify what state was being complained about. What hardware is this, and are what is the general configuration/workload of the Win10 guest? Thanks, ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [BUG] Invalid guest state in Xen master, dom0 linux-5.3.6, domU windows 10
Got this just now, as my windows domU died: (XEN) [2019-10-15 21:23:44] d7v0 vmentry failure (reason 0x8021): Invalid guest state (0) (XEN) [2019-10-15 21:23:44] * VMCS Area ** (XEN) [2019-10-15 21:23:44] *** Guest State *** (XEN) [2019-10-15 21:23:44] CR0: actual=0x80050031, shadow=0x80050031, gh_mask= (XEN) [2019-10-15 21:23:44] CR4: actual=0x00172678, shadow=0x00170678, gh_mask=ffe8f860 (XEN) [2019-10-15 21:23:44] CR3 = 0x001aa002 (XEN) [2019-10-15 21:23:44] RSP = 0x908e440fae68 (0x908e440fae68) RIP = 0x9581e15d560b (0x9581e15d560b) (XEN) [2019-10-15 21:23:44] RFLAGS=0x0197 (0x0197) DR7 = 0x0400 (XEN) [2019-10-15 21:23:44] Sysenter RSP= CS:RIP=: (XEN) [2019-10-15 21:23:44] sel attr limit base (XEN) [2019-10-15 21:23:56] printk: 52 messages suppressed. (XEN) [2019-10-15 21:23:56] [VT-D]d7:PCIe: unmap :81:00.0 (XEN) [2019-10-15 21:23:56] [VT-D]d0:PCIe: map :81:00.0 (XEN) [2019-10-15 21:23:59] printk: 2 messages suppressed. (XEN) [2019-10-15 21:23:59] [VT-D]d7:PCIe: unmap :02:00.0 # xl info host : gentoo release : 5.3.6-gentoo-r1 version : #2 SMP Sat Oct 12 13:48:00 CEST 2019 machine : x86_64 nr_cpus : 12 max_cpu_id : 11 nr_nodes : 2 cores_per_socket : 6 threads_per_core : 1 cpu_mhz : 2471.973 hw_caps : bfebfbff:77fef3ff:2c100800:0021:0001:37ab::0100 virt_caps : pv hvm hvm_directio pv_directio hap shadow iommu_hap_pt_share total_memory : 65376 free_memory : 12996 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 13 xen_extra : -unstable xen_version : 4.13-unstable xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit2 xen_pagesize : 4096 platform_params : virt_start=0x8000 xen_changeset : xen_commandline : xen.cfg xen-marker-215 console_timestamps=date iommu=1,intpost,verbose,debug iommu_inclusive_mapping=1 com1=57600,8n1 com2=57600,8n1 console=vga,com2 dom0_max_vcpus=8 dom0_mem=8G,max:8G cpufreq=xen:performance,verbose smt=0 maxcpus=12 core_parking=performance nmi=dom0 gnttab_max_frames=256 gnttab_max_maptrack_frames=1024 vcpu_migration_delay=2000 tickle_one_idle_cpu=1 spec-ctrl=no-xen sched=credit2 max_cstate=2 clocksource=tsc tsc=stable:socket timer_slop=5000 loglvl=none/warning guest_loglvl=none/warning cc_compiler : gcc (Gentoo 8.3.0-r1 p1.1) 8.3.0 cc_compile_by : hakon cc_compile_domain : alstadheim.priv.no cc_compile_date : Sun Oct 13 16:18:01 CEST 2019 build_id : c67e3aeeb910fcd06dfe7bd31a9eb820 xend_config_format : 4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
On 15/10/2019 21:38, Stefano Stabellini wrote: > On Tue, 15 Oct 2019, Julien Grall wrote: >> Hi, >> >> On 15/10/2019 20:28, Stefano Stabellini wrote: >>> On Tue, 15 Oct 2019, Julien Grall wrote: virt_to_maddr() is using the hardware page-table walk instructions to translate a virtual address to physical address. The function should only be called on virtual address mapped. _end points past the end of Xen binary and may not be mapped when the binary size is page-aligned. This means virt_to_maddr() will not be able to do the translation and therefore crash Xen. Note there is also an off-by-one issue in this code, but the panic will trump that. Both issues can be fixed by using _end - 1 in the check. Signed-off-by: Julien Grall --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu Cc: jgr...@suse.com x86 seems to be affected by the off-by-one issue. Jan, Andrew? This could be reached by a domain via XEN_SYSCTL_page_offline_op. However, the operation is not security supported (see XSA-77). So we are fine here. --- xen/include/asm-arm/mm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h index 262d92f18d..174acd8859 100644 --- a/xen/include/asm-arm/mm.h +++ b/xen/include/asm-arm/mm.h @@ -153,7 +153,7 @@ extern unsigned long xenheap_base_pdx; #define is_xen_fixed_mfn(mfn) \ ((mfn_to_maddr(mfn) >= virt_to_maddr(&_start)) && \ - (mfn_to_maddr(mfn) <= virt_to_maddr(&_end))) + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1))) >>> >>> Thank you for sending the patch and I think that "_end - 1" is the right >>> fix. I am just wondering whether we want/need an explicit cast of some >>> sort here, because technically _end is a char[] and 1 is a integer. >>> Maybe: >>> >>> ((vaddr_t)_end - 1) >>> >>> ? >> >> I vaguely remember a lengthy discussion about it last year. But I don't >> think there was any conclusion in it. >> >> In this case, what are you trying to prevent with the cast? Is it >> underflow of an array? If so, how the cast is actually going to prevent >> the compiler to do the wrong thing? > > Yes, there was a long discussion at the beginning of the year; it was > about how to define _start and _end so that we could avoid compilers > undefined behavior. The main underlying issue is that comparisons > between pointers to different objects are undefined [1] (_start and _end > can be interpreted as pointers to different objects). > > This case is a bit different, and easier. The issue is that, because the > result of "_end - 1" is not within the boundaries of the _end array, > then the operation is "undefined" by the C specification (C99 6.5.6). > Undefined is not good. > > So, I am not really asking for any complex fix, or hypervisor-wide > rework. I am only asking to avoid introducing new undefined behavior. > Casting to vaddr_t should solve it I think. I agree that we should not add more undefined behavior in Xen. However, I don't like cast if they can't be justified. In this particular case, you seem to be unsure this is going to remove an undefined behavior. IIRC, I pointed out in the past that compiler can see through cast. So can we have some certainty that your suggestion is going to work? Cheers, > > [1] https://marc.info/?l=xen-devel=15490477312 > -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
On Tue, 15 Oct 2019, Julien Grall wrote: > Hi, > > On 15/10/2019 20:28, Stefano Stabellini wrote: > > On Tue, 15 Oct 2019, Julien Grall wrote: > >> virt_to_maddr() is using the hardware page-table walk instructions to > >> translate a virtual address to physical address. The function should > >> only be called on virtual address mapped. > >> > >> _end points past the end of Xen binary and may not be mapped when the > >> binary size is page-aligned. This means virt_to_maddr() will not be able > >> to do the translation and therefore crash Xen. > >> > >> Note there is also an off-by-one issue in this code, but the panic will > >> trump that. > >> > >> Both issues can be fixed by using _end - 1 in the check. > >> > >> Signed-off-by: Julien Grall > >> > >> --- > >> > >> Cc: Andrew Cooper > >> Cc: George Dunlap > >> Cc: Ian Jackson > >> Cc: Jan Beulich > >> Cc: Julien Grall > >> Cc: Konrad Rzeszutek Wilk > >> Cc: Stefano Stabellini > >> Cc: Tim Deegan > >> Cc: Wei Liu > >> Cc: jgr...@suse.com > >> > >> x86 seems to be affected by the off-by-one issue. Jan, Andrew? > >> > >> This could be reached by a domain via XEN_SYSCTL_page_offline_op. > >> However, the operation is not security supported (see XSA-77). So we are > >> fine here. > >> --- > >> xen/include/asm-arm/mm.h | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h > >> index 262d92f18d..174acd8859 100644 > >> --- a/xen/include/asm-arm/mm.h > >> +++ b/xen/include/asm-arm/mm.h > >> @@ -153,7 +153,7 @@ extern unsigned long xenheap_base_pdx; > >> > >> #define is_xen_fixed_mfn(mfn) \ > >> ((mfn_to_maddr(mfn) >= virt_to_maddr(&_start)) && \ > >> - (mfn_to_maddr(mfn) <= virt_to_maddr(&_end))) > >> + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1))) > > > > Thank you for sending the patch and I think that "_end - 1" is the right > > fix. I am just wondering whether we want/need an explicit cast of some > > sort here, because technically _end is a char[] and 1 is a integer. > > Maybe: > > > >((vaddr_t)_end - 1) > > > > ? > > I vaguely remember a lengthy discussion about it last year. But I don't > think there was any conclusion in it. > > In this case, what are you trying to prevent with the cast? Is it > underflow of an array? If so, how the cast is actually going to prevent > the compiler to do the wrong thing? Yes, there was a long discussion at the beginning of the year; it was about how to define _start and _end so that we could avoid compilers undefined behavior. The main underlying issue is that comparisons between pointers to different objects are undefined [1] (_start and _end can be interpreted as pointers to different objects). This case is a bit different, and easier. The issue is that, because the result of "_end - 1" is not within the boundaries of the _end array, then the operation is "undefined" by the C specification (C99 6.5.6). Undefined is not good. So, I am not really asking for any complex fix, or hypervisor-wide rework. I am only asking to avoid introducing new undefined behavior. Casting to vaddr_t should solve it I think. [1] https://marc.info/?l=xen-devel=15490477312 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 142757: regressions - FAIL
flight 142757 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/142757/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-examine 8 reboot fail REGR. vs. 133580 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 133580 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 133580 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 17 guest-start.2fail REGR. vs. 133580 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 133580 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 133580 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
Hi, On 15/10/2019 20:28, Stefano Stabellini wrote: > On Tue, 15 Oct 2019, Julien Grall wrote: >> virt_to_maddr() is using the hardware page-table walk instructions to >> translate a virtual address to physical address. The function should >> only be called on virtual address mapped. >> >> _end points past the end of Xen binary and may not be mapped when the >> binary size is page-aligned. This means virt_to_maddr() will not be able >> to do the translation and therefore crash Xen. >> >> Note there is also an off-by-one issue in this code, but the panic will >> trump that. >> >> Both issues can be fixed by using _end - 1 in the check. >> >> Signed-off-by: Julien Grall >> >> --- >> >> Cc: Andrew Cooper >> Cc: George Dunlap >> Cc: Ian Jackson >> Cc: Jan Beulich >> Cc: Julien Grall >> Cc: Konrad Rzeszutek Wilk >> Cc: Stefano Stabellini >> Cc: Tim Deegan >> Cc: Wei Liu >> Cc: jgr...@suse.com >> >> x86 seems to be affected by the off-by-one issue. Jan, Andrew? >> >> This could be reached by a domain via XEN_SYSCTL_page_offline_op. >> However, the operation is not security supported (see XSA-77). So we are >> fine here. >> --- >> xen/include/asm-arm/mm.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h >> index 262d92f18d..174acd8859 100644 >> --- a/xen/include/asm-arm/mm.h >> +++ b/xen/include/asm-arm/mm.h >> @@ -153,7 +153,7 @@ extern unsigned long xenheap_base_pdx; >> >> #define is_xen_fixed_mfn(mfn) \ >> ((mfn_to_maddr(mfn) >= virt_to_maddr(&_start)) && \ >> - (mfn_to_maddr(mfn) <= virt_to_maddr(&_end))) >> + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1))) > > Thank you for sending the patch and I think that "_end - 1" is the right > fix. I am just wondering whether we want/need an explicit cast of some > sort here, because technically _end is a char[] and 1 is a integer. > Maybe: > >((vaddr_t)_end - 1) > > ? I vaguely remember a lengthy discussion about it last year. But I don't think there was any conclusion in it. In this case, what are you trying to prevent with the cast? Is it underflow of an array? If so, how the cast is actually going to prevent the compiler to do the wrong thing? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13 v3] xen/arm: mm: Allow generic xen page-tables helpers to be called early
On Tue, 15 Oct 2019, Julien Grall wrote:
> The current implementations of xen_{map, unmap}_table() expect
> {map, unmap}_domain_page() to be usable. Those helpers are used to
> map/unmap page tables while update Xen page-tables.
>
> Since commit 022387ee1a "xen/arm: mm: Don't open-code Xen PT update in
> {set, clear}_fixmap()", setup_fixmap() will make use of the helpers
> mentioned above. When booting Xen using GRUB, setup_fixmap() may be used
> before map_domain_page() can be called. This will result to data abort:
>
> (XEN) Data Abort Trap. Syndrome=0x5
> (XEN) CPU0: Unexpected Trap: Data Abort
>
> [...]
>
> (XEN) Xen call trace:
> (XEN)[<0025ab6c>] mm.c#xen_pt_update+0x2b4/0x59c (PC)
> (XEN)[<0025ab20>] mm.c#xen_pt_update+0x268/0x59c (LR)
> (XEN)[<0025ae70>] set_fixmap+0x1c/0x2c
> (XEN)[<002a9c98>] copy_from_paddr+0x7c/0xdc
> (XEN)[<002a4ae0>] has_xsm_magic+0x18/0x34
> (XEN)[<002a5b5c>] bootfdt.c#early_scan_node+0x398/0x560
> (XEN)[<002a5de0>] device_tree_for_each_node+0xbc/0x144
> (XEN)[<002a5ed4>] boot_fdt_info+0x6c/0x260
> (XEN)[<002ac0d0>] start_xen+0x108/0xc74
> (XEN)[<0020044c>] arm64/head.o#paging+0x60/0x88
>
> During early boot, the page tables are either statically allocated in
> Xen binary or allocated via alloc_boot_pages().
>
> For statically allocated page-tables, they will already be mapped as
> part of Xen binary. So we can easily find the virtual address.
>
> For dynamically allocated page-tables, we need to rely
> map_domain_page() to be functionally working.
>
> For arm32, the call will be usable much before page can be dynamically
> allocated (see setup_pagetables()). For arm64, the call will be usable
> after setup_xenheap_mappings().
>
> In both cases, memory are given to the boot allocator afterwards. So we
> can rely on map_domain_page() for mapping page tables allocated
> dynamically.
>
> The helpers xen_{map, unmap}_table() are now updated to take into
> account the case where page-tables are part of Xen binary.
>
> Fixes: 022387ee1a ('xen/arm: mm: Don't open-code Xen PT update in {set,
> clear}_fixmap()')
> Signed-off-by: Julien Grall
> Release-acked-by: Juergen Gross
Reviewed-by: Stefano Stabellini
> ---
> Changes in v3:
> - Use is_xen_fixed_mfn
> - Add a comment about demoting the type.
>
> Changes in v2:
> - Add RaB Juergen
> - Rework the check to avoid truncation
>
> Note this patch relies on is_xen_fixed_mfn to be correct (see [1]).
>
> [1] https://lists.xen.org/archives/html/xen-devel/2019-10/msg01138.html
> ---
> xen/arch/arm/mm.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index be23acfe26..4514bc6bb0 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -964,11 +964,41 @@ static int create_xen_table(lpae_t *entry)
>
> static lpae_t *xen_map_table(mfn_t mfn)
> {
> +/*
> + * We may require to map the page table before map_domain_page() is
> + * useable. The requirements here is it must be useable as soon as
> + * page-tables are allocated dynamically via alloc_boot_pages().
> + *
> + * We need to do the check on physical address rather than virtual
> + * address to avoid truncation on Arm32. Therefore is_kernel() cannot
> + * be used.
> + */
> +if ( system_state == SYS_STATE_early_boot )
> +{
> +if ( is_xen_fixed_mfn(mfn) )
> +{
> +/*
> + * It is fine to demote the type because the size of Xen
> + * will always fit in vaddr_t.
> + */
> +vaddr_t offset = mfn_to_maddr(mfn) - virt_to_maddr(&_start);
> +
> +return (lpae_t *)(XEN_VIRT_START + offset);
> +}
> +}
> +
> return map_domain_page(mfn);
> }
>
> static void xen_unmap_table(const lpae_t *table)
> {
> +/*
> + * During early boot, xen_map_table() will not use map_domain_page()
> + * for page-tables residing in Xen binary. So skip the unmap part.
> + */
> +if ( system_state == SYS_STATE_early_boot && is_kernel(table) )
> +return;
> +
> unmap_domain_page(table);
> }
>
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
On Tue, 15 Oct 2019, Julien Grall wrote: > virt_to_maddr() is using the hardware page-table walk instructions to > translate a virtual address to physical address. The function should > only be called on virtual address mapped. > > _end points past the end of Xen binary and may not be mapped when the > binary size is page-aligned. This means virt_to_maddr() will not be able > to do the translation and therefore crash Xen. > > Note there is also an off-by-one issue in this code, but the panic will > trump that. > > Both issues can be fixed by using _end - 1 in the check. > > Signed-off-by: Julien Grall > > --- > > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Julien Grall > Cc: Konrad Rzeszutek Wilk > Cc: Stefano Stabellini > Cc: Tim Deegan > Cc: Wei Liu > Cc: jgr...@suse.com > > x86 seems to be affected by the off-by-one issue. Jan, Andrew? > > This could be reached by a domain via XEN_SYSCTL_page_offline_op. > However, the operation is not security supported (see XSA-77). So we are > fine here. > --- > xen/include/asm-arm/mm.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h > index 262d92f18d..174acd8859 100644 > --- a/xen/include/asm-arm/mm.h > +++ b/xen/include/asm-arm/mm.h > @@ -153,7 +153,7 @@ extern unsigned long xenheap_base_pdx; > > #define is_xen_fixed_mfn(mfn) \ > ((mfn_to_maddr(mfn) >= virt_to_maddr(&_start)) && \ > - (mfn_to_maddr(mfn) <= virt_to_maddr(&_end))) > + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1))) Thank you for sending the patch and I think that "_end - 1" is the right fix. I am just wondering whether we want/need an explicit cast of some sort here, because technically _end is a char[] and 1 is a integer. Maybe: ((vaddr_t)_end - 1) ? ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 22/34] xen: Use CONFIG_PREEMPTION
From: Thomas Gleixner
CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
Both PREEMPT and PREEMPT_RT require the same functionality which today
depends on CONFIG_PREEMPT.
Switch the preempt anand xen-ops code over to use CONFIG_PREEMPTION.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/xen/preempt.c | 4 ++--
include/xen/xen-ops.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/preempt.c b/drivers/xen/preempt.c
index 8b9919c26095d..70650b248de5d 100644
--- a/drivers/xen/preempt.c
+++ b/drivers/xen/preempt.c
@@ -8,7 +8,7 @@
#include
#include
-#ifndef CONFIG_PREEMPT
+#ifndef CONFIG_PREEMPTION
/*
* Some hypercalls issued by the toolstack can take many 10s of
@@ -37,4 +37,4 @@ asmlinkage __visible void xen_maybe_preempt_hcall(void)
__this_cpu_write(xen_in_preemptible_hcall, true);
}
}
-#endif /* CONFIG_PREEMPT */
+#endif /* CONFIG_PREEMPTION */
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index d89969aa9942c..095be1d66f31c 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -215,7 +215,7 @@ bool xen_running_on_version_or_later(unsigned int major,
unsigned int minor);
void xen_efi_runtime_setup(void);
-#ifdef CONFIG_PREEMPT
+#ifdef CONFIG_PREEMPTION
static inline void xen_preemptible_hcall_begin(void)
{
@@ -239,6 +239,6 @@ static inline void xen_preemptible_hcall_end(void)
__this_cpu_write(xen_in_preemptible_hcall, false);
}
-#endif /* CONFIG_PREEMPT */
+#endif /* CONFIG_PREEMPTION */
#endif /* INCLUDE_XEN_OPS_H */
--
2.23.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.13 v3] xen/arm: mm: Allow generic xen page-tables helpers to be called early
The current implementations of xen_{map, unmap}_table() expect
{map, unmap}_domain_page() to be usable. Those helpers are used to
map/unmap page tables while update Xen page-tables.
Since commit 022387ee1a "xen/arm: mm: Don't open-code Xen PT update in
{set, clear}_fixmap()", setup_fixmap() will make use of the helpers
mentioned above. When booting Xen using GRUB, setup_fixmap() may be used
before map_domain_page() can be called. This will result to data abort:
(XEN) Data Abort Trap. Syndrome=0x5
(XEN) CPU0: Unexpected Trap: Data Abort
[...]
(XEN) Xen call trace:
(XEN)[<0025ab6c>] mm.c#xen_pt_update+0x2b4/0x59c (PC)
(XEN)[<0025ab20>] mm.c#xen_pt_update+0x268/0x59c (LR)
(XEN)[<0025ae70>] set_fixmap+0x1c/0x2c
(XEN)[<002a9c98>] copy_from_paddr+0x7c/0xdc
(XEN)[<002a4ae0>] has_xsm_magic+0x18/0x34
(XEN)[<002a5b5c>] bootfdt.c#early_scan_node+0x398/0x560
(XEN)[<002a5de0>] device_tree_for_each_node+0xbc/0x144
(XEN)[<002a5ed4>] boot_fdt_info+0x6c/0x260
(XEN)[<002ac0d0>] start_xen+0x108/0xc74
(XEN)[<0020044c>] arm64/head.o#paging+0x60/0x88
During early boot, the page tables are either statically allocated in
Xen binary or allocated via alloc_boot_pages().
For statically allocated page-tables, they will already be mapped as
part of Xen binary. So we can easily find the virtual address.
For dynamically allocated page-tables, we need to rely
map_domain_page() to be functionally working.
For arm32, the call will be usable much before page can be dynamically
allocated (see setup_pagetables()). For arm64, the call will be usable
after setup_xenheap_mappings().
In both cases, memory are given to the boot allocator afterwards. So we
can rely on map_domain_page() for mapping page tables allocated
dynamically.
The helpers xen_{map, unmap}_table() are now updated to take into
account the case where page-tables are part of Xen binary.
Fixes: 022387ee1a ('xen/arm: mm: Don't open-code Xen PT update in {set,
clear}_fixmap()')
Signed-off-by: Julien Grall
Release-acked-by: Juergen Gross
---
Changes in v3:
- Use is_xen_fixed_mfn
- Add a comment about demoting the type.
Changes in v2:
- Add RaB Juergen
- Rework the check to avoid truncation
Note this patch relies on is_xen_fixed_mfn to be correct (see [1]).
[1] https://lists.xen.org/archives/html/xen-devel/2019-10/msg01138.html
---
xen/arch/arm/mm.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index be23acfe26..4514bc6bb0 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -964,11 +964,41 @@ static int create_xen_table(lpae_t *entry)
static lpae_t *xen_map_table(mfn_t mfn)
{
+/*
+ * We may require to map the page table before map_domain_page() is
+ * useable. The requirements here is it must be useable as soon as
+ * page-tables are allocated dynamically via alloc_boot_pages().
+ *
+ * We need to do the check on physical address rather than virtual
+ * address to avoid truncation on Arm32. Therefore is_kernel() cannot
+ * be used.
+ */
+if ( system_state == SYS_STATE_early_boot )
+{
+if ( is_xen_fixed_mfn(mfn) )
+{
+/*
+ * It is fine to demote the type because the size of Xen
+ * will always fit in vaddr_t.
+ */
+vaddr_t offset = mfn_to_maddr(mfn) - virt_to_maddr(&_start);
+
+return (lpae_t *)(XEN_VIRT_START + offset);
+}
+}
+
return map_domain_page(mfn);
}
static void xen_unmap_table(const lpae_t *table)
{
+/*
+ * During early boot, xen_map_table() will not use map_domain_page()
+ * for page-tables residing in Xen binary. So skip the unmap part.
+ */
+if ( system_state == SYS_STATE_early_boot && is_kernel(table) )
+return;
+
unmap_domain_page(table);
}
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 142765: all pass - PUSHED
flight 142765 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/142765/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf cd70b1a71d30d0fff4c549a309682fdf127aaae6 baseline version: ovmf 410c4d00d9f7e369d1ce183e9e8de98cb59c4d20 Last test of basis 142423 2019-10-08 01:39:34 Z7 days Failing since142455 2019-10-08 19:21:52 Z6 days 12 attempts Testing same since 142765 2019-10-15 06:13:43 Z0 days1 attempts People who touched revisions under test: Agrawal, Sachin Ard Biesheuvel Bob Feng Feng, Bob C Jiewen Yao Laszlo Ersek Pete Batard Sachin Agrawal jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 410c4d00d9..cd70b1a71d cd70b1a71d30d0fff4c549a309682fdf127aaae6 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] libxl_pci: Fix guest shutdown with PCI PT attached
On 15/10/2019 18:59, Sander Eikelenboom wrote: > On 14/10/2019 17:03, Chao Gao wrote: >> On Thu, Oct 10, 2019 at 06:13:43PM +0200, Sander Eikelenboom wrote: >>> On 01/10/2019 12:35, Anthony PERARD wrote: Rewrite of the commit message: Before the problematic commit, libxl used to ignore error when destroying (force == true) a passthrough device, especially error that happens when dealing with the DM. Since fae4880c45fe, if the DM failed to detach the pci device within the allowed time, the timed out error raised skip part of pci_remove_*, but also raise the error up to the caller of libxl__device_pci_destroy_all, libxl__destroy_domid, and thus the destruction of the domain fails. In this patch, if the DM didn't confirmed that the device is removed, we will print a warning and keep going if force=true. The patch reorder the functions so that pci_remove_timeout() calls pci_remove_detatched() like it's done when DM calls are successful. We also clean the QMP states and associated timeouts earlier, as soon as they are not needed anymore. Reported-by: Sander Eikelenboom Fixes: fae4880c45fe015e567afa223f78bf17a6d98e1b Signed-off-by: Anthony PERARD >>> >>> Hi Anthony / Chao, >>> >>> I have to come back to this, a bit because perhaps there is an underlying >>> issue. >>> While it earlier occurred to me that the VM to which I passed through most >>> pci-devices >>> (8 to be exact) became very slow to shutdown, but I didn't investigate it >>> further. >>> >>> But after you commit messages from this patch it kept nagging, so today I >>> did some testing >>> and bisecting. >>> >>> The difference in tear-down time at least from what the IOMMU code logs is >>> quite large: >>> >>> xen-4.12.0 >>> Setup: 7.452 s >>> Tear-down: 7.626 s >>> >>> xen-unstable-ee7170822f1fc209f33feb47b268bab35541351d >>> Setup: 7.468 s >>> Tear-down: 50.239 s >>> >>> Bisection turned up: >>> commit c4b1ef0f89aa6a74faa4618ce3efed1de246ec40 >>> Author: Chao Gao >>> Date: Fri Jul 19 10:24:08 2019 +0100 >>> libxl_qmp: wait for completion of device removal >>> >>> Which makes me wonder if there is something going wrong in Qemu ? > >> Hi Sander, > Hi Chao, > >> >> Thanks for your testing and the bisection. >> >> I tried on my machine, the destruction time of a guest with 8 pass-thru >> devices increased from 4s to 12s after applied the commit above. > > To what patch are you referring Anthony's or > c4b1ef0f89aa6a74faa4618ce3efed1de246ec40 ? > >> In my understanding, I guess you might get the error message "timed out >> waiting for DM to remove...". There might be some issues on your assigned >> devices' drivers. You can first unbind the devices with their drivers in >> VM and then tear down the VM, and check whether the VM teardown gets >> much faster. Sorry I forgot to answer your question, I tried unbinding the drivers in the guest prior to shutting it down, but it didn't make any difference. -- Sander > I get that error message when I test with Anthony's patch applied, the > destruction time with that patch is low. > > How ever my point was if that patch is correct in the sense that there seems > to be an underlying issue > which causes it to take so long. That issue was uncovered by > c4b1ef0f89aa6a74faa4618ce3efed1de246ec40, so I'm not > saying that commit is wrong in any sense, it just uncovered another issue > that was already present, > but hard to detect as we just didn't wait at destruction time (and thus the > same effect as a timeout). > > One or the other way that was just a minor issue until > fae4880c45fe015e567afa223f78bf17a6d98e1b, where the long > destruction time now caused the domain destruction to stall, which was then > fixed by Antony's patch, but that uses > a timeout which kinds of circumvents the issue, instead of finding out where > is comes from and solve it there ( > if that is possible of course). > > And I wonder if Anthony's patch doesn't interfere with the case you made > c4b1ef0f89aa6a74faa4618ce3efed1de246ec40 for, > if you get the timeout error message as well, then that is kind of not > waiting for the destruction to finish, isn't it ? > > Chao, > could you perhaps test for me Xen with as latest commit > ee7170822f1fc209f33feb47b268bab35541351d ? > That is before Anthony's patch series, but after your > c4b1ef0f89aa6a74faa4618ce3efed1de246ec40. > > I would expect to see longer destruction times in the case of 8 pass-throuh > devices as well. > > Unfortunately Qemu doesn't seem to do much verbose logging even when i enable > the debug defines in hw/xen, > especially for the destruction side of things (it mostly logs setting up > stuff). > > -- > Sander > > > > >> Anthony & Wei, >> >> The commit above basically serializes and synchronizes detaching >> assigned devices and thus increases VM teardown
[Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
virt_to_maddr() is using the hardware page-table walk instructions to translate a virtual address to physical address. The function should only be called on virtual address mapped. _end points past the end of Xen binary and may not be mapped when the binary size is page-aligned. This means virt_to_maddr() will not be able to do the translation and therefore crash Xen. Note there is also an off-by-one issue in this code, but the panic will trump that. Both issues can be fixed by using _end - 1 in the check. Signed-off-by: Julien Grall --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu Cc: jgr...@suse.com x86 seems to be affected by the off-by-one issue. Jan, Andrew? This could be reached by a domain via XEN_SYSCTL_page_offline_op. However, the operation is not security supported (see XSA-77). So we are fine here. --- xen/include/asm-arm/mm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h index 262d92f18d..174acd8859 100644 --- a/xen/include/asm-arm/mm.h +++ b/xen/include/asm-arm/mm.h @@ -153,7 +153,7 @@ extern unsigned long xenheap_base_pdx; #define is_xen_fixed_mfn(mfn) \ ((mfn_to_maddr(mfn) >= virt_to_maddr(&_start)) && \ - (mfn_to_maddr(mfn) <= virt_to_maddr(&_end))) + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1))) #define page_get_owner(_p)(_p)->v.inuse.domain #define page_set_owner(_p,_d) ((_p)->v.inuse.domain = (_d)) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH hmm 09/15] xen/gntdev: use mmu_range_notifier_insert
From: Jason Gunthorpe
gntdev simply wants to monitor a specific VMA for any notifier events,
this can be done straightforwardly using mmu_range_notifier_insert() over
the VMA's VA range.
The notifier should be attached until the original VMA is destroyed.
It is unclear if any of this is even sane, but at least a lot of duplicate
code is removed.
Cc: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: xen-devel@lists.xenproject.org
Cc: Juergen Gross
Cc: Stefano Stabellini
Signed-off-by: Jason Gunthorpe
---
drivers/xen/gntdev-common.h | 8 +-
drivers/xen/gntdev.c| 179 ++--
2 files changed, 48 insertions(+), 139 deletions(-)
diff --git a/drivers/xen/gntdev-common.h b/drivers/xen/gntdev-common.h
index 2f8b949c3eeb14..b201fdd20b667b 100644
--- a/drivers/xen/gntdev-common.h
+++ b/drivers/xen/gntdev-common.h
@@ -21,15 +21,8 @@ struct gntdev_dmabuf_priv;
struct gntdev_priv {
/* Maps with visible offsets in the file descriptor. */
struct list_head maps;
- /*
-* Maps that are not visible; will be freed on munmap.
-* Only populated if populate_freeable_maps == 1
-*/
- struct list_head freeable_maps;
/* lock protects maps and freeable_maps. */
struct mutex lock;
- struct mm_struct *mm;
- struct mmu_notifier mn;
#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
/* Device for which DMA memory is allocated. */
@@ -49,6 +42,7 @@ struct gntdev_unmap_notify {
};
struct gntdev_grant_map {
+ struct mmu_range_notifier notifier;
struct list_head next;
struct vm_area_struct *vma;
int index;
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index a446a7221e13e9..234153f556afd6 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -65,7 +65,6 @@ MODULE_PARM_DESC(limit, "Maximum number of grants that may be
mapped by "
static atomic_t pages_mapped = ATOMIC_INIT(0);
static int use_ptemod;
-#define populate_freeable_maps use_ptemod
static int unmap_grant_pages(struct gntdev_grant_map *map,
int offset, int pages);
@@ -251,12 +250,6 @@ void gntdev_put_map(struct gntdev_priv *priv, struct
gntdev_grant_map *map)
evtchn_put(map->notify.event);
}
- if (populate_freeable_maps && priv) {
- mutex_lock(>lock);
- list_del(>next);
- mutex_unlock(>lock);
- }
-
if (map->pages && !use_ptemod)
unmap_grant_pages(map, 0, map->count);
gntdev_free_map(map);
@@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma)
struct gntdev_priv *priv = file->private_data;
pr_debug("gntdev_vma_close %p\n", vma);
- if (use_ptemod) {
- /* It is possible that an mmu notifier could be running
-* concurrently, so take priv->lock to ensure that the vma won't
-* vanishing during the unmap_grant_pages call, since we will
-* spin here until that completes. Such a concurrent call will
-* not do any unmapping, since that has been done prior to
-* closing the vma, but it may still iterate the unmap_ops list.
-*/
- mutex_lock(>lock);
+ if (use_ptemod && map->vma == vma) {
+ mmu_range_notifier_remove(>notifier);
map->vma = NULL;
- mutex_unlock(>lock);
}
vma->vm_private_data = NULL;
gntdev_put_map(priv, map);
@@ -477,109 +462,43 @@ static const struct vm_operations_struct gntdev_vmops = {
/* -- */
-static bool in_range(struct gntdev_grant_map *map,
- unsigned long start, unsigned long end)
-{
- if (!map->vma)
- return false;
- if (map->vma->vm_start >= end)
- return false;
- if (map->vma->vm_end <= start)
- return false;
-
- return true;
-}
-
-static int unmap_if_in_range(struct gntdev_grant_map *map,
- unsigned long start, unsigned long end,
- bool blockable)
+static bool gntdev_invalidate(struct mmu_range_notifier *mn,
+ const struct mmu_notifier_range *range)
{
+ struct gntdev_grant_map *map =
+ container_of(mn, struct gntdev_grant_map, notifier);
unsigned long mstart, mend;
int err;
- if (!in_range(map, start, end))
- return 0;
+ if (!mmu_notifier_range_blockable(range))
+ return false;
- if (!blockable)
- return -EAGAIN;
+ /*
+* If the VMA is split or otherwise changed the notifier is not
+* updated, but we don't want to process VA's outside the modified
+* VMA. FIXME: It would be much more understandable to just prevent
+* modifying the
[Xen-devel] [PATCH hmm 08/15] xen/gntdev: Use select for DMA_SHARED_BUFFER
From: Jason Gunthorpe
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are turned on implicitly when the user enables a kconfig
that needs them.
Otherwise the XEN_GNTDEV_DMABUF kconfig is overly difficult to enable.
Fixes: 932d6562179e ("xen/gntdev: Add initial support for dma-buf UAPI")
Cc: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: xen-devel@lists.xenproject.org
Cc: Juergen Gross
Cc: Stefano Stabellini
Signed-off-by: Jason Gunthorpe
---
drivers/xen/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 79cc75096f4232..a50dadd0109336 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -141,7 +141,8 @@ config XEN_GNTDEV
config XEN_GNTDEV_DMABUF
bool "Add support for dma-buf grant access device driver extension"
- depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC && DMA_SHARED_BUFFER
+ depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC
+ select DMA_SHARED_BUFFER
help
Allows userspace processes and kernel modules to use Xen backed
dma-buf implementation. With this extension grant references to
--
2.23.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 142761: regressions - FAIL
flight 142761 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/142761/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs. 142644 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 142644 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 142644 test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt 9d03e9adf1776104290e7c7d3368e58998f27987 baseline version: libvirt 36138eaecf8920d843ca3b1cec38cc765369144c Last test of basis 142644 2019-10-12 04:18:51 Z3 days Testing same since 142761 2019-10-15 04:18:46 Z0 days1 attempts People who touched revisions under test: Daniel P. Berrangé Michal Privoznik jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 435 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org
Re: [Xen-devel] [PATCH 2/2] libxl_pci: Fix guest shutdown with PCI PT attached
On 14/10/2019 17:03, Chao Gao wrote: > On Thu, Oct 10, 2019 at 06:13:43PM +0200, Sander Eikelenboom wrote: >> On 01/10/2019 12:35, Anthony PERARD wrote: >>> Rewrite of the commit message: >>> >>> Before the problematic commit, libxl used to ignore error when >>> destroying (force == true) a passthrough device, especially error that >>> happens when dealing with the DM. >>> >>> Since fae4880c45fe, if the DM failed to detach the pci device within >>> the allowed time, the timed out error raised skip part of >>> pci_remove_*, but also raise the error up to the caller of >>> libxl__device_pci_destroy_all, libxl__destroy_domid, and thus the >>> destruction of the domain fails. >>> >>> In this patch, if the DM didn't confirmed that the device is removed, >>> we will print a warning and keep going if force=true. The patch >>> reorder the functions so that pci_remove_timeout() calls >>> pci_remove_detatched() like it's done when DM calls are successful. >>> >>> We also clean the QMP states and associated timeouts earlier, as soon >>> as they are not needed anymore. >>> >>> Reported-by: Sander Eikelenboom >>> Fixes: fae4880c45fe015e567afa223f78bf17a6d98e1b >>> Signed-off-by: Anthony PERARD >>> >> >> Hi Anthony / Chao, >> >> I have to come back to this, a bit because perhaps there is an underlying >> issue. >> While it earlier occurred to me that the VM to which I passed through most >> pci-devices >> (8 to be exact) became very slow to shutdown, but I didn't investigate it >> further. >> >> But after you commit messages from this patch it kept nagging, so today I >> did some testing >> and bisecting. >> >> The difference in tear-down time at least from what the IOMMU code logs is >> quite large: >> >> xen-4.12.0 >> Setup: 7.452 s >> Tear-down: 7.626 s >> >> xen-unstable-ee7170822f1fc209f33feb47b268bab35541351d >> Setup: 7.468 s >> Tear-down: 50.239 s >> >> Bisection turned up: >> commit c4b1ef0f89aa6a74faa4618ce3efed1de246ec40 >> Author: Chao Gao >> Date: Fri Jul 19 10:24:08 2019 +0100 >> libxl_qmp: wait for completion of device removal >> >> Which makes me wonder if there is something going wrong in Qemu ? > Hi Sander, Hi Chao, > > Thanks for your testing and the bisection. > > I tried on my machine, the destruction time of a guest with 8 pass-thru > devices increased from 4s to 12s after applied the commit above. To what patch are you referring Anthony's or c4b1ef0f89aa6a74faa4618ce3efed1de246ec40 ? > In my understanding, I guess you might get the error message "timed out > waiting for DM to remove...". There might be some issues on your assigned > devices' drivers. You can first unbind the devices with their drivers in > VM and then tear down the VM, and check whether the VM teardown gets > much faster. I get that error message when I test with Anthony's patch applied, the destruction time with that patch is low. How ever my point was if that patch is correct in the sense that there seems to be an underlying issue which causes it to take so long. That issue was uncovered by c4b1ef0f89aa6a74faa4618ce3efed1de246ec40, so I'm not saying that commit is wrong in any sense, it just uncovered another issue that was already present, but hard to detect as we just didn't wait at destruction time (and thus the same effect as a timeout). One or the other way that was just a minor issue until fae4880c45fe015e567afa223f78bf17a6d98e1b, where the long destruction time now caused the domain destruction to stall, which was then fixed by Antony's patch, but that uses a timeout which kinds of circumvents the issue, instead of finding out where is comes from and solve it there ( if that is possible of course). And I wonder if Anthony's patch doesn't interfere with the case you made c4b1ef0f89aa6a74faa4618ce3efed1de246ec40 for, if you get the timeout error message as well, then that is kind of not waiting for the destruction to finish, isn't it ? Chao, could you perhaps test for me Xen with as latest commit ee7170822f1fc209f33feb47b268bab35541351d ? That is before Anthony's patch series, but after your c4b1ef0f89aa6a74faa4618ce3efed1de246ec40. I would expect to see longer destruction times in the case of 8 pass-throuh devices as well. Unfortunately Qemu doesn't seem to do much verbose logging even when i enable the debug defines in hw/xen, especially for the destruction side of things (it mostly logs setting up stuff). -- Sander > Anthony & Wei, > > The commit above basically serializes and synchronizes detaching > assigned devices and thus increases VM teardown time significantly if > there are multiple assigned devices. The commit aimed to avoid qemu's > access to PCI configuration space coinciding with the device reset > initiated by xl (which is not desired and is exactly the case which > triggers the assertion in Xen [1]). I personally insist that xl should > wait for DM's completion of device detaching. Otherwise, besides Xen
Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm
On 10/15/19 5:47 PM, Stefano Stabellini wrote: I am OK switching to "Arm", however I would do it post-4.13: this is not the kind of thing we should worry about it now I think. ok, I will move to my next queue. Cheers, On Tue, 15 Oct 2019, Julien Grall wrote: Hi, Gentle, ping. I don't think there are any conclusion here. Should we stick to ARM or move to Arm? Cheers, On 10/3/19 5:02 PM, Julien Grall wrote: Hi, On 03/10/2019 16:55, Volodymyr Babchuk wrote: Julien Grall writes: Hi Stefano, On 10/2/19 2:05 AM, Stefano Stabellini wrote: On Tue, 24 Sep 2019, Julien Grall wrote: The documentation is using a mix of ARM (old) and Arm (new). To stay consistent, use only the new name. Thank you for the patch, it must have been "not fun" to write this patch. However, let me suggest a radical maybe controversial idea. What about keeping "ARM" instead of switching? There are several advantages: it is easier to grep, no need to worry about case-sensitivity. It is what people are used to, and what still use (in my experience at conference and at work.) Would it make sense to ignore Arm's marketing and keep the old "ARM" nomenclature? Pretty much all the new documentation on Arm website are now using Arm (the spec is now called Arm Arm). This confuses me, because I believed that second "Arm" stands for Architecture Reference Manual. Sorry it is Arm ARM. But they tend to use the longer name Arm Architecture Reference Manual. If not, I'd suggest to also replace "arm" with "Arm" so that at least with have consistent cases everywhere. But then the pathnames would remain xen/arch/arm, leading to sentences such as: (non-zImage)" protocol described in arm/Booting. There are no exception on 64-bit Arm. With "arm" and "ARM" the distinction was clear between pathnames and text (at least to me.) With "arm" and "Arm", I know it is silly but it kind of bothers me :-) How do you deal with Xilinx then? ;) I am not going to insist on this one though. This is quite similar to a company renaming itself (or got acquired and the name completely disappear) but in a less radical way. Would you still keep the old name company in your documentation and/or mixing the both? BTW, this if what happened with Freescale/NXP. Linux and U-Boot still use "freescale" even for i.MX8 chips. Maybe because nobody bothered to do it? I would like some consistency in the documentation and hence using the new name makes sense. But I am not bothered enough to argue whether we should stay in the past. Cheers, -- Julien Grall -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm
I am OK switching to "Arm", however I would do it post-4.13: this is not the kind of thing we should worry about it now I think. On Tue, 15 Oct 2019, Julien Grall wrote: > Hi, > > Gentle, ping. I don't think there are any conclusion here. > > Should we stick to ARM or move to Arm? > > Cheers, > > On 10/3/19 5:02 PM, Julien Grall wrote: > > Hi, > > > > On 03/10/2019 16:55, Volodymyr Babchuk wrote: > > > Julien Grall writes: > > > > > > > Hi Stefano, > > > > > > > > On 10/2/19 2:05 AM, Stefano Stabellini wrote: > > > > > On Tue, 24 Sep 2019, Julien Grall wrote: > > > > > > The documentation is using a mix of ARM (old) and Arm (new). To stay > > > > > > consistent, use only the new name. > > > > > > > > > > Thank you for the patch, it must have been "not fun" to write this > > > > > patch. > > > > > > > > > > However, let me suggest a radical maybe controversial idea. What about > > > > > keeping "ARM" instead of switching? There are several advantages: it > > > > > is > > > > > easier to grep, no need to worry about case-sensitivity. It is what > > > > > people are used to, and what still use (in my experience at conference > > > > > and at work.) Would it make sense to ignore Arm's marketing and keep > > > > > the > > > > > old "ARM" nomenclature? > > > > > > > > Pretty much all the new documentation on Arm website are now using Arm > > > > (the spec is now called Arm Arm). > > > This confuses me, because I believed that second "Arm" stands for > > > Architecture Reference Manual. > > Sorry it is Arm ARM. But they tend to use the longer name Arm Architecture > > Reference Manual. > > > > > > > > > > > > > > > If not, I'd suggest to also replace "arm" with "Arm" so that at least > > > > > with have consistent cases everywhere. But then the pathnames would > > > > > remain xen/arch/arm, leading to sentences such as: > > > > > > > > > > (non-zImage)" protocol described in arm/Booting. > > > > > There are no exception on 64-bit Arm. > > > > > > > > > > With "arm" and "ARM" the distinction was clear between pathnames and > > > > > text (at least to me.) With "arm" and "Arm", I know it is silly but it > > > > > kind of bothers me :-) > > > > > > > > How do you deal with Xilinx then? ;) > > > > > > > > > > > > > > I am not going to insist on this one though. > > > > > > > > This is quite similar to a company renaming itself (or got acquired > > > > and the name completely disappear) but in a less radical way. Would > > > > you still keep the old name company in your documentation and/or > > > > mixing the both? > > > BTW, this if what happened with Freescale/NXP. Linux and U-Boot still > > > use "freescale" even for i.MX8 chips. > > > > Maybe because nobody bothered to do it? I would like some consistency in the > > documentation and hence using the new name makes sense. But I am not > > bothered enough to argue whether we should stay in the past. > > > > Cheers, > > > > -- > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/arm: domain_build: Print the correct domain in dtb_load()
Hi Juergen,
Gentle ping.
Cheers,
On 10/10/19 3:43 PM, Julien Grall wrote:
Hi,
Hmm, it looks like I forgot this patch before the freeze. Juergen, are
you happy with this to go in Xen 4.13?
Cheers,
On 15/08/2019 18:29, Julien Grall wrote:
dtb_load() can be called by other domain than dom0. To avoid confusion
in the log, print the correct domain.
Signed-off-by: Julien Grall
---
Changes in v2:
- Fix the second print in the function as well.
---
xen/arch/arm/domain_build.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4e51e22927..126374f603 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1787,15 +1787,17 @@ static void __init dtb_load(struct kernel_info
*kinfo)
{
unsigned long left;
- printk("Loading dom0 DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
- kinfo->dtb_paddr, kinfo->dtb_paddr +
fdt_totalsize(kinfo->fdt));
+ printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+ kinfo->d, kinfo->dtb_paddr,
+ kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
kinfo->fdt,
fdt_totalsize(kinfo->fdt));
if ( left != 0 )
- panic("Unable to copy the DTB to dom0 memory (left = %lu
bytes)\n", left);
+ panic("Unable to copy the DTB to %pd memory (left = %lu
bytes)\n",
+ kinfo->d, left);
xfree(kinfo->fdt);
}
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm
Hi, Gentle, ping. I don't think there are any conclusion here. Should we stick to ARM or move to Arm? Cheers, On 10/3/19 5:02 PM, Julien Grall wrote: Hi, On 03/10/2019 16:55, Volodymyr Babchuk wrote: Julien Grall writes: Hi Stefano, On 10/2/19 2:05 AM, Stefano Stabellini wrote: On Tue, 24 Sep 2019, Julien Grall wrote: The documentation is using a mix of ARM (old) and Arm (new). To stay consistent, use only the new name. Thank you for the patch, it must have been "not fun" to write this patch. However, let me suggest a radical maybe controversial idea. What about keeping "ARM" instead of switching? There are several advantages: it is easier to grep, no need to worry about case-sensitivity. It is what people are used to, and what still use (in my experience at conference and at work.) Would it make sense to ignore Arm's marketing and keep the old "ARM" nomenclature? Pretty much all the new documentation on Arm website are now using Arm (the spec is now called Arm Arm). This confuses me, because I believed that second "Arm" stands for Architecture Reference Manual. Sorry it is Arm ARM. But they tend to use the longer name Arm Architecture Reference Manual. If not, I'd suggest to also replace "arm" with "Arm" so that at least with have consistent cases everywhere. But then the pathnames would remain xen/arch/arm, leading to sentences such as: (non-zImage)" protocol described in arm/Booting. There are no exception on 64-bit Arm. With "arm" and "ARM" the distinction was clear between pathnames and text (at least to me.) With "arm" and "Arm", I know it is silly but it kind of bothers me :-) How do you deal with Xilinx then? ;) I am not going to insist on this one though. This is quite similar to a company renaming itself (or got acquired and the name completely disappear) but in a less radical way. Would you still keep the old name company in your documentation and/or mixing the both? BTW, this if what happened with Freescale/NXP. Linux and U-Boot still use "freescale" even for i.MX8 chips. Maybe because nobody bothered to do it? I would like some consistency in the documentation and hence using the new name makes sense. But I am not bothered enough to argue whether we should stay in the past. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RESEND][PATCH for-4.13] xen/arm: mm: Clear boot pagetables before bringing-up each secondary CPU
Hi,
I actually forgot to CC Juergen. No wonder why I had no answer :(.
Cheers,
On 10/10/19 3:51 PM, Julien Grall wrote:
+Juergen
On 03/10/2019 02:22, Stefano Stabellini wrote:
On Sat, 21 Sep 2019, Julien Grall wrote:
At the moment, boot pagetables are only cleared once at boot. This means
when booting CPU2 (and onwards) then boot pagetables will not be
cleared.
To keep the interface exactly the same for all secondary CPU, the boot
pagetables are now cleared before bringing-up each secondary CPU.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
xen/arch/arm/mm.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 1129dc28c8..e14ee76ff8 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -704,8 +704,20 @@ void __init setup_pagetables(unsigned long
boot_phys_offset)
switch_ttbr(ttbr);
- /* Clear the copy of the boot pagetables. Each secondary CPU
- * rebuilds these itself (see head.S) */
+ xen_pt_enforce_wnx();
+
+#ifdef CONFIG_ARM_32
+ per_cpu(xen_pgtable, 0) = cpu0_pgtable;
+ per_cpu(xen_dommap, 0) = cpu0_dommap;
+#endif
+}
+
+static void clear_boot_pagetables(void)
+{
+ /*
+ * Clear the copy of the boot pagetables. Each secondary CPU
+ * rebuilds these itself (see head.S)
+ */
clear_table(boot_pgtable);
#ifdef CONFIG_ARM_64
clear_table(boot_first);
@@ -713,18 +725,13 @@ void __init setup_pagetables(unsigned long
boot_phys_offset)
#endif
clear_table(boot_second);
clear_table(boot_third);
-
- xen_pt_enforce_wnx();
-
-#ifdef CONFIG_ARM_32
- per_cpu(xen_pgtable, 0) = cpu0_pgtable;
- per_cpu(xen_dommap, 0) = cpu0_dommap;
-#endif
}
#ifdef CONFIG_ARM_64
int init_secondary_pagetables(int cpu)
{
+ clear_boot_pagetables();
+
/* Set init_ttbr for this CPU coming up. All CPus share a
single setof
* pagetables, but rewrite it each time for consistency with 32
bit. */
init_ttbr = (uintptr_t) xen_pgtable + phys_offset;
@@ -767,6 +774,8 @@ int init_secondary_pagetables(int cpu)
per_cpu(xen_pgtable, cpu) = first;
per_cpu(xen_dommap, cpu) = domheap;
+ clear_boot_pagetables();
+
/* Set init_ttbr for this CPU coming up */
init_ttbr = __pa(first);
clean_dcache(init_ttbr);
--
2.11.0
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 32/32] hw/pci-host/i440fx: Remove the last PIIX3 traces
The PIIX3 is not tied to the i440FX and can even be used without it.
Move its creation to the machine code (pc_piix.c).
We have now removed the last trace of southbridge code in the i440FX
northbridge.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc_piix.c| 8 +++-
hw/pci-host/i440fx.c | 8
include/hw/pci-host/i440fx.h | 3 +--
3 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 8ac4bf12ca..cb4f4fc94c 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -190,14 +190,20 @@ static void pc_init1(MachineState *machine,
gsi_state = pc_gsi_create(>gsi, pcmc->pci_enabled);
if (pcmc->pci_enabled) {
+PIIX3State *piix3;
+
pci_bus = i440fx_init(host_type,
pci_type,
- _state, _devfn, _bus, pcms->gsi,
+ _state,
system_memory, system_io, machine->ram_size,
pcms->below_4g_mem_size,
pcms->above_4g_mem_size,
pci_memory, ram_memory);
pcms->bus = pci_bus;
+
+piix3 = piix3_create(pci_bus, _bus);
+piix3->pic = pcms->gsi;
+piix3_devfn = piix3->dev.devfn;
} else {
pci_bus = NULL;
i440fx_state = NULL;
diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c
index 79ecd58a2b..f27131102d 100644
--- a/hw/pci-host/i440fx.c
+++ b/hw/pci-host/i440fx.c
@@ -27,7 +27,6 @@
#include "hw/pci/pci.h"
#include "hw/pci/pci_host.h"
#include "hw/pci-host/i440fx.h"
-#include "hw/southbridge/piix.h"
#include "hw/qdev-properties.h"
#include "hw/sysbus.h"
#include "qapi/error.h"
@@ -272,8 +271,6 @@ static void i440fx_realize(PCIDevice *dev, Error **errp)
PCIBus *i440fx_init(const char *host_type, const char *pci_type,
PCII440FXState **pi440fx_state,
-int *piix3_devfn,
-ISABus **isa_bus, qemu_irq *pic,
MemoryRegion *address_space_mem,
MemoryRegion *address_space_io,
ram_addr_t ram_size,
@@ -286,7 +283,6 @@ PCIBus *i440fx_init(const char *host_type, const char
*pci_type,
PCIBus *b;
PCIDevice *d;
PCIHostState *s;
-PIIX3State *piix3;
PCII440FXState *f;
unsigned i;
I440FXState *i440fx;
@@ -339,10 +335,6 @@ PCIBus *i440fx_init(const char *host_type, const char
*pci_type,
PAM_EXPAN_SIZE);
}
-piix3 = piix3_create(b, isa_bus);
-piix3->pic = pic;
-*piix3_devfn = piix3->dev.devfn;
-
ram_size = ram_size / 8 / 1024 / 1024;
if (ram_size > 255) {
ram_size = 255;
diff --git a/include/hw/pci-host/i440fx.h b/include/hw/pci-host/i440fx.h
index e327f9bf87..f54e6466e4 100644
--- a/include/hw/pci-host/i440fx.h
+++ b/include/hw/pci-host/i440fx.h
@@ -22,8 +22,7 @@ typedef struct PCII440FXState PCII440FXState;
#define TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE "igd-passthrough-i440FX"
PCIBus *i440fx_init(const char *host_type, const char *pci_type,
-PCII440FXState **pi440fx_state, int *piix_devfn,
-ISABus **isa_bus, qemu_irq *pic,
+PCII440FXState **pi440fx_state,
MemoryRegion *address_space_mem,
MemoryRegion *address_space_io,
ram_addr_t ram_size,
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 29/32] hw/pci-host/piix: Fix code style issues
We will move this code, fix its style first.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/piix.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index 0b5da5bc94..61f91ff561 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -133,9 +133,10 @@ static PCIINTxRoute piix3_route_intx_pin_to_irq(void
*opaque, int pci_intx);
static void piix3_write_config_xen(PCIDevice *dev,
uint32_t address, uint32_t val, int len);
-/* return the global irq number corresponding to a given device irq
- pin. We could also use the bus number to have a more precise
- mapping. */
+/*
+ * Return the global irq number corresponding to a given device irq
+ * pin. We could also use the bus number to have a more precise mapping.
+ */
static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
{
int slot_addend;
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 31/32] hw/pci-host: Rename incorrectly named 'piix' as 'i440fx'
From: Philippe Mathieu-Daudé
We moved all the PIIX3 southbridge code out of hw/pci-host/piix.c,
it now only contains i440FX northbridge code.
Rename it to match the chipset modelled.
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 2 +-
hw/i386/Kconfig | 2 +-
hw/pci-host/Kconfig | 2 +-
hw/pci-host/Makefile.objs| 2 +-
hw/pci-host/{piix.c => i440fx.c} | 0
5 files changed, 4 insertions(+), 4 deletions(-)
rename hw/pci-host/{piix.c => i440fx.c} (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4845f47d93..1bc9959b8a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1225,7 +1225,7 @@ M: Marcel Apfelbaum
S: Supported
F: include/hw/i386/
F: hw/i386/
-F: hw/pci-host/piix.c
+F: hw/pci-host/i440fx.c
F: hw/pci-host/q35.c
F: hw/pci-host/pam.c
F: include/hw/pci-host/i440fx.h
diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index 589d75e26a..cfe94aede7 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -60,7 +60,7 @@ config I440FX
select PC_PCI
select PC_ACPI
select ACPI_SMBUS
-select PCI_PIIX
+select PCI_I440FX
select PIIX3
select IDE_PIIX
select DIMM
diff --git a/hw/pci-host/Kconfig b/hw/pci-host/Kconfig
index 397043b289..b0aa8351c4 100644
--- a/hw/pci-host/Kconfig
+++ b/hw/pci-host/Kconfig
@@ -28,7 +28,7 @@ config PCI_SABRE
select PCI
bool
-config PCI_PIIX
+config PCI_I440FX
bool
select PCI
select PAM
diff --git a/hw/pci-host/Makefile.objs b/hw/pci-host/Makefile.objs
index a9cd3e022d..efd752b766 100644
--- a/hw/pci-host/Makefile.objs
+++ b/hw/pci-host/Makefile.objs
@@ -13,7 +13,7 @@ common-obj-$(CONFIG_VERSATILE_PCI) += versatile.o
common-obj-$(CONFIG_PCI_SABRE) += sabre.o
common-obj-$(CONFIG_FULONG) += bonito.o
-common-obj-$(CONFIG_PCI_PIIX) += piix.o
+common-obj-$(CONFIG_PCI_I440FX) += i440fx.o
common-obj-$(CONFIG_PCI_EXPRESS_Q35) += q35.o
common-obj-$(CONFIG_PCI_EXPRESS_GENERIC_BRIDGE) += gpex.o
common-obj-$(CONFIG_PCI_EXPRESS_XILINX) += xilinx-pcie.o
diff --git a/hw/pci-host/piix.c b/hw/pci-host/i440fx.c
similarity index 100%
rename from hw/pci-host/piix.c
rename to hw/pci-host/i440fx.c
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 30/32] hw/pci-host/piix: Extract PIIX3 functions to hw/isa/piix3.c
From: Philippe Mathieu-Daudé
Move all the PIIX3 functions to a new file: hw/isa/piix3.c.
Signed-off-by: Philippe Mathieu-Daudé
---
Checkpatch warning:
ERROR: spaces required around that '*' (ctx:VxV)
#312: FILE: hw/isa/piix3.c:248:
+.subsections = (const VMStateDescription*[]) {
^
---
MAINTAINERS | 1 +
hw/i386/Kconfig | 1 +
hw/isa/Kconfig| 4 +
hw/isa/Makefile.objs | 1 +
hw/isa/piix3.c| 399 +
hw/pci-host/Kconfig | 1 -
hw/pci-host/piix.c| 402 --
include/hw/southbridge/piix.h | 36 +++
8 files changed, 442 insertions(+), 403 deletions(-)
create mode 100644 hw/isa/piix3.c
diff --git a/MAINTAINERS b/MAINTAINERS
index adf059a164..4845f47d93 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1231,6 +1231,7 @@ F: hw/pci-host/pam.c
F: include/hw/pci-host/i440fx.h
F: include/hw/pci-host/q35.h
F: include/hw/pci-host/pam.h
+F: hw/isa/piix3.c
F: hw/isa/lpc_ich9.c
F: hw/i2c/smbus_ich9.c
F: hw/acpi/piix4.c
diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index c5c9d4900e..589d75e26a 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -61,6 +61,7 @@ config I440FX
select PC_ACPI
select ACPI_SMBUS
select PCI_PIIX
+select PIIX3
select IDE_PIIX
select DIMM
select SMBIOS
diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig
index 98a289957e..8a38813cc1 100644
--- a/hw/isa/Kconfig
+++ b/hw/isa/Kconfig
@@ -29,6 +29,10 @@ config PC87312
select FDC
select IDE_ISA
+config PIIX3
+bool
+select ISA_BUS
+
config PIIX4
bool
# For historical reasons, SuperIO devices are created in the board
diff --git a/hw/isa/Makefile.objs b/hw/isa/Makefile.objs
index ff97485504..8e73960a75 100644
--- a/hw/isa/Makefile.objs
+++ b/hw/isa/Makefile.objs
@@ -3,6 +3,7 @@ common-obj-$(CONFIG_ISA_SUPERIO) += isa-superio.o
common-obj-$(CONFIG_APM) += apm.o
common-obj-$(CONFIG_I82378) += i82378.o
common-obj-$(CONFIG_PC87312) += pc87312.o
+common-obj-$(CONFIG_PIIX3) += piix3.o
common-obj-$(CONFIG_PIIX4) += piix4.o
common-obj-$(CONFIG_VT82C686) += vt82c686.o
common-obj-$(CONFIG_SMC37C669) += smc37c669-superio.o
diff --git a/hw/isa/piix3.c b/hw/isa/piix3.c
new file mode 100644
index 00..05146447ef
--- /dev/null
+++ b/hw/isa/piix3.c
@@ -0,0 +1,399 @@
+/*
+ * QEMU PIIX PCI ISA Bridge Emulation
+ *
+ * Copyright (c) 2006 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/range.h"
+#include "hw/southbridge/piix.h"
+#include "hw/irq.h"
+#include "hw/isa/isa.h"
+#include "hw/xen/xen.h"
+#include "sysemu/sysemu.h"
+#include "sysemu/reset.h"
+#include "sysemu/runstate.h"
+#include "migration/vmstate.h"
+
+#define XEN_PIIX_NUM_PIRQS 128ULL
+
+#define TYPE_PIIX3_PCI_DEVICE "pci-piix3"
+#define PIIX3_PCI_DEVICE(obj) \
+OBJECT_CHECK(PIIX3State, (obj), TYPE_PIIX3_PCI_DEVICE)
+
+#define TYPE_PIIX3_DEVICE "PIIX3"
+#define TYPE_PIIX3_XEN_DEVICE "PIIX3-xen"
+
+static void piix3_set_irq_pic(PIIX3State *piix3, int pic_irq)
+{
+qemu_set_irq(piix3->pic[pic_irq],
+ !!(piix3->pic_levels &
+(((1ULL << PIIX_NUM_PIRQS) - 1) <<
+ (pic_irq * PIIX_NUM_PIRQS;
+}
+
+static void piix3_set_irq_level_internal(PIIX3State *piix3, int pirq, int
level)
+{
+int pic_irq;
+uint64_t mask;
+
+pic_irq = piix3->dev.config[PIIX_PIRQCA + pirq];
+if (pic_irq >= PIIX_NUM_PIC_IRQS) {
+return;
+}
+
+mask = 1ULL << ((pic_irq * PIIX_NUM_PIRQS) + pirq);
+piix3->pic_levels &= ~mask;
+piix3->pic_levels |= mask * !!level;
+}
+
+static void piix3_set_irq_level(PIIX3State *piix3, int pirq, int level)
+{
+int pic_irq;
+
+pic_irq = piix3->dev.config[PIIX_PIRQCA + pirq];
+if (pic_irq >= PIIX_NUM_PIC_IRQS) {
+
[Xen-devel] [PATCH 27/32] hw/pci-host/piix: Define and use the PIIX IRQ Route Control Registers
The IRQ Route Control registers definitions belong to the PIIX
chipset. We were only defining the 'A' register. Define the other
B, C and D registers, and use them.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen-hvm.c | 5 +++--
hw/mips/gt64xxx_pci.c | 4 ++--
hw/pci-host/piix.c| 9 -
include/hw/southbridge/piix.h | 6 ++
4 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 6b5e5bb7f5..4ce2fb9c89 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -14,6 +14,7 @@
#include "hw/pci/pci.h"
#include "hw/pci/pci_host.h"
#include "hw/i386/pc.h"
+#include "hw/southbridge/piix.h"
#include "hw/irq.h"
#include "hw/hw.h"
#include "hw/i386/apic-msidef.h"
@@ -156,8 +157,8 @@ void xen_piix_pci_write_config_client(uint32_t address,
uint32_t val, int len)
v = 0;
}
v &= 0xf;
-if (((address + i) >= 0x60) && ((address + i) <= 0x63)) {
-xen_set_pci_link_route(xen_domid, address + i - 0x60, v);
+if (((address + i) >= PIIX_PIRQCA) && ((address + i) <= PIIX_PIRQCD)) {
+xen_set_pci_link_route(xen_domid, address + i - PIIX_PIRQCA, v);
}
}
}
diff --git a/hw/mips/gt64xxx_pci.c b/hw/mips/gt64xxx_pci.c
index c277398c0d..5cab9c1ee1 100644
--- a/hw/mips/gt64xxx_pci.c
+++ b/hw/mips/gt64xxx_pci.c
@@ -1013,12 +1013,12 @@ static void gt64120_pci_set_irq(void *opaque, int
irq_num, int level)
/* now we change the pic irq level according to the piix irq mappings */
/* XXX: optimize */
-pic_irq = piix4_dev->config[0x60 + irq_num];
+pic_irq = piix4_dev->config[PIIX_PIRQCA + irq_num];
if (pic_irq < 16) {
/* The pic level is the logical OR of all the PCI irqs mapped to it. */
pic_level = 0;
for (i = 0; i < 4; i++) {
-if (pic_irq == piix4_dev->config[0x60 + i]) {
+if (pic_irq == piix4_dev->config[PIIX_PIRQCA + i]) {
pic_level |= pci_irq_levels[i];
}
}
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index 3770575c1a..a450fc726e 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -61,7 +61,6 @@ typedef struct I440FXState {
#define PIIX_NUM_PIC_IRQS 16 /* i8259 * 2 */
#define PIIX_NUM_PIRQS 4ULL/* PIRQ[A-D] */
#define XEN_PIIX_NUM_PIRQS 128ULL
-#define PIIX_PIRQC 0x60
typedef struct PIIX3State {
PCIDevice dev;
@@ -468,7 +467,7 @@ static void piix3_set_irq_level_internal(PIIX3State *piix3,
int pirq, int level)
int pic_irq;
uint64_t mask;
-pic_irq = piix3->dev.config[PIIX_PIRQC + pirq];
+pic_irq = piix3->dev.config[PIIX_PIRQCA + pirq];
if (pic_irq >= PIIX_NUM_PIC_IRQS) {
return;
}
@@ -482,7 +481,7 @@ static void piix3_set_irq_level(PIIX3State *piix3, int
pirq, int level)
{
int pic_irq;
-pic_irq = piix3->dev.config[PIIX_PIRQC + pirq];
+pic_irq = piix3->dev.config[PIIX_PIRQCA + pirq];
if (pic_irq >= PIIX_NUM_PIC_IRQS) {
return;
}
@@ -501,7 +500,7 @@ static void piix3_set_irq(void *opaque, int pirq, int level)
static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pin)
{
PIIX3State *piix3 = opaque;
-int irq = piix3->dev.config[PIIX_PIRQC + pin];
+int irq = piix3->dev.config[PIIX_PIRQCA + pin];
PCIINTxRoute route;
if (irq < PIIX_NUM_PIC_IRQS) {
@@ -530,7 +529,7 @@ static void piix3_write_config(PCIDevice *dev,
uint32_t address, uint32_t val, int len)
{
pci_default_write_config(dev, address, val, len);
-if (ranges_overlap(address, len, PIIX_PIRQC, 4)) {
+if (ranges_overlap(address, len, PIIX_PIRQCA, 4)) {
PIIX3State *piix3 = PIIX3_PCI_DEVICE(dev);
int pic_irq;
diff --git a/include/hw/southbridge/piix.h b/include/hw/southbridge/piix.h
index 79ebe0089b..9c92c37a4d 100644
--- a/include/hw/southbridge/piix.h
+++ b/include/hw/southbridge/piix.h
@@ -18,6 +18,12 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t
smb_io_base,
qemu_irq sci_irq, qemu_irq smi_irq,
int smm_enabled, DeviceState **piix4_pm);
+/* PIRQRC[A:D]: PIRQx Route Control Registers */
+#define PIIX_PIRQCA 0x60
+#define PIIX_PIRQCB 0x61
+#define PIIX_PIRQCC 0x62
+#define PIIX_PIRQCD 0x63
+
/*
* Reset Control Register: PCI-accessible ISA-Compatible Register at address
* 0xcf9, provided by the PCI/ISA bridge (PIIX3 PCI function 0, 8086:7000).
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 28/32] hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.h
From: Philippe Mathieu-Daudé
The hw/pci-host/piix.c contains a mix of PIIX3 and i440FX chipsets
functions. To be able to split it, we need to export some
declarations first.
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 1 +
hw/acpi/pcihp.c | 2 +-
hw/i386/pc_piix.c| 1 +
hw/pci-host/piix.c | 1 +
include/hw/i386/pc.h | 22 -
include/hw/pci-host/i440fx.h | 37
stubs/pci-host-piix.c| 3 ++-
7 files changed, 43 insertions(+), 24 deletions(-)
create mode 100644 include/hw/pci-host/i440fx.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 556f58bd8c..adf059a164 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1228,6 +1228,7 @@ F: hw/i386/
F: hw/pci-host/piix.c
F: hw/pci-host/q35.c
F: hw/pci-host/pam.c
+F: include/hw/pci-host/i440fx.h
F: include/hw/pci-host/q35.h
F: include/hw/pci-host/pam.h
F: hw/isa/lpc_ich9.c
diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
index 82d295b6e8..8413348a33 100644
--- a/hw/acpi/pcihp.c
+++ b/hw/acpi/pcihp.c
@@ -27,7 +27,7 @@
#include "qemu/osdep.h"
#include "hw/acpi/pcihp.h"
-#include "hw/i386/pc.h"
+#include "hw/pci-host/i440fx.h"
#include "hw/pci/pci.h"
#include "hw/pci/pci_bridge.h"
#include "hw/acpi/acpi.h"
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 5b35ff04c7..8ac4bf12ca 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -29,6 +29,7 @@
#include "hw/loader.h"
#include "hw/i386/pc.h"
#include "hw/i386/apic.h"
+#include "hw/pci-host/i440fx.h"
#include "hw/southbridge/piix.h"
#include "hw/display/ramfb.h"
#include "hw/firmware/smbios.h"
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index a450fc726e..0b5da5bc94 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -27,6 +27,7 @@
#include "hw/irq.h"
#include "hw/pci/pci.h"
#include "hw/pci/pci_host.h"
+#include "hw/pci-host/i440fx.h"
#include "hw/southbridge/piix.h"
#include "hw/qdev-properties.h"
#include "hw/isa/isa.h"
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 1c20b96571..cead2828de 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -248,28 +248,6 @@ int cmos_get_fd_drive_type(FloppyDriveType fd0);
/* hpet.c */
extern int no_hpet;
-/* piix_pci.c */
-struct PCII440FXState;
-typedef struct PCII440FXState PCII440FXState;
-
-#define TYPE_I440FX_PCI_HOST_BRIDGE "i440FX-pcihost"
-#define TYPE_I440FX_PCI_DEVICE "i440FX"
-
-#define TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE "igd-passthrough-i440FX"
-
-PCIBus *i440fx_init(const char *host_type, const char *pci_type,
-PCII440FXState **pi440fx_state, int *piix_devfn,
-ISABus **isa_bus, qemu_irq *pic,
-MemoryRegion *address_space_mem,
-MemoryRegion *address_space_io,
-ram_addr_t ram_size,
-ram_addr_t below_4g_mem_size,
-ram_addr_t above_4g_mem_size,
-MemoryRegion *pci_memory,
-MemoryRegion *ram_memory);
-
-PCIBus *find_i440fx(void);
-
/* pc_sysfw.c */
void pc_system_flash_create(PCMachineState *pcms);
void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory);
diff --git a/include/hw/pci-host/i440fx.h b/include/hw/pci-host/i440fx.h
new file mode 100644
index 00..e327f9bf87
--- /dev/null
+++ b/include/hw/pci-host/i440fx.h
@@ -0,0 +1,37 @@
+/*
+ * QEMU i440FX North Bridge Emulation
+ *
+ * Copyright (c) 2006 Fabrice Bellard
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef HW_PCI_I440FX_H
+#define HW_PCI_I440FX_H
+
+#include "hw/hw.h"
+#include "hw/pci/pci_bus.h"
+
+typedef struct PCII440FXState PCII440FXState;
+
+#define TYPE_I440FX_PCI_HOST_BRIDGE "i440FX-pcihost"
+#define TYPE_I440FX_PCI_DEVICE "i440FX"
+
+#define TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE "igd-passthrough-i440FX"
+
+PCIBus *i440fx_init(const char *host_type, const char *pci_type,
+PCII440FXState **pi440fx_state, int *piix_devfn,
+ISABus **isa_bus, qemu_irq *pic,
+MemoryRegion *address_space_mem,
+MemoryRegion *address_space_io,
+ram_addr_t ram_size,
+ram_addr_t below_4g_mem_size,
+ram_addr_t above_4g_mem_size,
+MemoryRegion *pci_memory,
+MemoryRegion *ram_memory);
+
+PCIBus *find_i440fx(void);
+
+#endif
diff --git a/stubs/pci-host-piix.c b/stubs/pci-host-piix.c
index 6ed81b1f21..93975adbfe 100644
--- a/stubs/pci-host-piix.c
+++ b/stubs/pci-host-piix.c
@@ -1,5 +1,6 @@
#include "qemu/osdep.h"
-#include "hw/i386/pc.h"
+#include "hw/pci-host/i440fx.h"
+
PCIBus *find_i440fx(void)
{
return NULL;
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
[Xen-devel] [PATCH 26/32] hw/pci-host/piix: Move RCR_IOPORT register definition
From: Philippe Mathieu-Daudé The RCR_IOPORT register belongs to the PIIX chipset. Move the definition to "piix.h". Signed-off-by: Philippe Mathieu-Daudé --- hw/pci-host/piix.c| 1 + include/hw/i386/pc.h | 6 -- include/hw/southbridge/piix.h | 6 ++ 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c index 3292703de7..3770575c1a 100644 --- a/hw/pci-host/piix.c +++ b/hw/pci-host/piix.c @@ -27,6 +27,7 @@ #include "hw/irq.h" #include "hw/pci/pci.h" #include "hw/pci/pci_host.h" +#include "hw/southbridge/piix.h" #include "hw/qdev-properties.h" #include "hw/isa/isa.h" #include "hw/sysbus.h" diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h index 183326d9fe..1c20b96571 100644 --- a/include/hw/i386/pc.h +++ b/include/hw/i386/pc.h @@ -257,12 +257,6 @@ typedef struct PCII440FXState PCII440FXState; #define TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE "igd-passthrough-i440FX" -/* - * Reset Control Register: PCI-accessible ISA-Compatible Register at address - * 0xcf9, provided by the PCI/ISA bridge (PIIX3 PCI function 0, 8086:7000). - */ -#define RCR_IOPORT 0xcf9 - PCIBus *i440fx_init(const char *host_type, const char *pci_type, PCII440FXState **pi440fx_state, int *piix_devfn, ISABus **isa_bus, qemu_irq *pic, diff --git a/include/hw/southbridge/piix.h b/include/hw/southbridge/piix.h index add352456b..79ebe0089b 100644 --- a/include/hw/southbridge/piix.h +++ b/include/hw/southbridge/piix.h @@ -18,6 +18,12 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base, qemu_irq sci_irq, qemu_irq smi_irq, int smm_enabled, DeviceState **piix4_pm); +/* + * Reset Control Register: PCI-accessible ISA-Compatible Register at address + * 0xcf9, provided by the PCI/ISA bridge (PIIX3 PCI function 0, 8086:7000). + */ +#define RCR_IOPORT 0xcf9 + extern PCIDevice *piix4_dev; DeviceState *piix4_create(PCIBus *pci_bus, ISABus **isa_bus, -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 25/32] hw/pci-host/piix: Extract piix3_create()
Extract the PIIX3 creation code from the i440fx_init() function.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/piix.c | 51 --
1 file changed, 31 insertions(+), 20 deletions(-)
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index 2f4cbcbfe9..3292703de7 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -331,6 +331,36 @@ static void i440fx_realize(PCIDevice *dev, Error **errp)
}
}
+static PIIX3State *piix3_create(PCIBus *pci_bus, ISABus **isa_bus)
+{
+PIIX3State *piix3;
+PCIDevice *pci_dev;
+
+/*
+ * Xen supports additional interrupt routes from the PCI devices to
+ * the IOAPIC: the four pins of each PCI device on the bus are also
+ * connected to the IOAPIC directly.
+ * These additional routes can be discovered through ACPI.
+ */
+if (xen_enabled()) {
+pci_dev = pci_create_simple_multifunction(pci_bus, -1, true,
+ TYPE_PIIX3_XEN_DEVICE);
+piix3 = PIIX3_PCI_DEVICE(pci_dev);
+pci_bus_irqs(pci_bus, xen_piix3_set_irq, xen_pci_slot_get_pirq,
+ piix3, XEN_PIIX_NUM_PIRQS);
+} else {
+pci_dev = pci_create_simple_multifunction(pci_bus, -1, true,
+ TYPE_PIIX3_DEVICE);
+piix3 = PIIX3_PCI_DEVICE(pci_dev);
+pci_bus_irqs(pci_bus, piix3_set_irq, pci_slot_get_pirq,
+ piix3, PIIX_NUM_PIRQS);
+pci_bus_set_route_irq_fn(pci_bus, piix3_route_intx_pin_to_irq);
+}
+*isa_bus = ISA_BUS(qdev_get_child_bus(DEVICE(piix3), "isa.0"));
+
+return piix3;
+}
+
PCIBus *i440fx_init(const char *host_type, const char *pci_type,
PCII440FXState **pi440fx_state,
int *piix3_devfn,
@@ -400,27 +430,8 @@ PCIBus *i440fx_init(const char *host_type, const char
*pci_type,
PAM_EXPAN_SIZE);
}
-/* Xen supports additional interrupt routes from the PCI devices to
- * the IOAPIC: the four pins of each PCI device on the bus are also
- * connected to the IOAPIC directly.
- * These additional routes can be discovered through ACPI. */
-if (xen_enabled()) {
-PCIDevice *pci_dev = pci_create_simple_multifunction(b,
- -1, true, TYPE_PIIX3_XEN_DEVICE);
-piix3 = PIIX3_PCI_DEVICE(pci_dev);
-pci_bus_irqs(b, xen_piix3_set_irq, xen_pci_slot_get_pirq,
-piix3, XEN_PIIX_NUM_PIRQS);
-} else {
-PCIDevice *pci_dev = pci_create_simple_multifunction(b,
- -1, true, TYPE_PIIX3_DEVICE);
-piix3 = PIIX3_PCI_DEVICE(pci_dev);
-pci_bus_irqs(b, piix3_set_irq, pci_slot_get_pirq, piix3,
-PIIX_NUM_PIRQS);
-pci_bus_set_route_irq_fn(b, piix3_route_intx_pin_to_irq);
-}
+piix3 = piix3_create(b, isa_bus);
piix3->pic = pic;
-*isa_bus = ISA_BUS(qdev_get_child_bus(DEVICE(piix3), "isa.0"));
-
*piix3_devfn = piix3->dev.devfn;
ram_size = ram_size / 8 / 1024 / 1024;
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 23/32] hw/i386/pc: Extract pc_i8259_create()
The i8259 creation code is common to all PC machines, extract the
common code.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc.c | 19 +++
hw/i386/pc_piix.c| 13 +
hw/i386/pc_q35.c | 14 +-
include/hw/i386/pc.h | 1 +
4 files changed, 22 insertions(+), 25 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 59de0c8a1f..2b6a52f23b 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1978,6 +1978,25 @@ void pc_nic_init(PCMachineClass *pcmc, ISABus *isa_bus,
PCIBus *pci_bus)
rom_reset_order_override();
}
+void pc_i8259_create(ISABus *isa_bus, qemu_irq *i8259_irqs)
+{
+qemu_irq *i8259;
+
+if (kvm_pic_in_kernel()) {
+i8259 = kvm_i8259_init(isa_bus);
+} else if (xen_enabled()) {
+i8259 = xen_interrupt_controller_init();
+} else {
+i8259 = i8259_init(isa_bus, pc_allocate_cpu_irq());
+}
+
+for (size_t i = 0; i < ISA_NUM_IRQS; i++) {
+i8259_irqs[i] = i8259[i];
+}
+
+g_free(i8259);
+}
+
void ioapic_init_gsi(GSIState *gsi_state, const char *parent_name)
{
DeviceState *dev;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 452b107e1b..0a7193a3cc 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -81,7 +81,6 @@ static void pc_init1(MachineState *machine,
ISABus *isa_bus;
PCII440FXState *i440fx_state;
int piix3_devfn = -1;
-qemu_irq *i8259;
qemu_irq smi_irq;
GSIState *gsi_state;
DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
@@ -208,18 +207,8 @@ static void pc_init1(MachineState *machine,
}
isa_bus_irqs(isa_bus, pcms->gsi);
-if (kvm_pic_in_kernel()) {
-i8259 = kvm_i8259_init(isa_bus);
-} else if (xen_enabled()) {
-i8259 = xen_interrupt_controller_init();
-} else {
-i8259 = i8259_init(isa_bus, pc_allocate_cpu_irq());
-}
+pc_i8259_create(isa_bus, gsi_state->i8259_irq);
-for (i = 0; i < ISA_NUM_IRQS; i++) {
-gsi_state->i8259_irq[i] = i8259[i];
-}
-g_free(i8259);
if (pcmc->pci_enabled) {
ioapic_init_gsi(gsi_state, "i440fx");
}
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 6d096eff28..f4fb9a02ba 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -128,7 +128,6 @@ static void pc_q35_init(MachineState *machine)
MemoryRegion *ram_memory;
GSIState *gsi_state;
ISABus *isa_bus;
-qemu_irq *i8259;
int i;
ICH9LPCState *ich9_lpc;
PCIDevice *ahci;
@@ -255,18 +254,7 @@ static void pc_q35_init(MachineState *machine)
pci_bus_set_route_irq_fn(host_bus, ich9_route_intx_pin_to_irq);
isa_bus = ich9_lpc->isa_bus;
-if (kvm_pic_in_kernel()) {
-i8259 = kvm_i8259_init(isa_bus);
-} else if (xen_enabled()) {
-i8259 = xen_interrupt_controller_init();
-} else {
-i8259 = i8259_init(isa_bus, pc_allocate_cpu_irq());
-}
-
-for (i = 0; i < ISA_NUM_IRQS; i++) {
-gsi_state->i8259_irq[i] = i8259[i];
-}
-g_free(i8259);
+pc_i8259_create(isa_bus, gsi_state->i8259_irq);
if (pcmc->pci_enabled) {
ioapic_init_gsi(gsi_state, "q35");
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 75b44e156c..183326d9fe 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -235,6 +235,7 @@ void pc_pci_device_init(PCIBus *pci_bus);
typedef void (*cpu_set_smm_t)(int smm, void *arg);
+void pc_i8259_create(ISABus *isa_bus, qemu_irq *i8259_irqs);
void ioapic_init_gsi(GSIState *gsi_state, const char *parent_name);
ISADevice *pc_find_fdc0(void);
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 24/32] hw/i386/pc: Remove kvm_i386.h include
By extracting pc_gsi_create() and pc_i8259_create() we removed the access to "kvm_i386.h" from the machine code. We can now remove it. Signed-off-by: Philippe Mathieu-Daudé --- hw/i386/pc_piix.c | 1 - hw/i386/pc_q35.c | 1 - 2 files changed, 2 deletions(-) diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 0a7193a3cc..5b35ff04c7 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -57,7 +57,6 @@ #endif #include "migration/global_state.h" #include "migration/misc.h" -#include "kvm_i386.h" #include "sysemu/numa.h" #define MAX_IDE_BUS 2 diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c index f4fb9a02ba..2e5d6821fb 100644 --- a/hw/i386/pc_q35.c +++ b/hw/i386/pc_q35.c @@ -36,7 +36,6 @@ #include "hw/timer/mc146818rtc.h" #include "hw/xen/xen.h" #include "sysemu/kvm.h" -#include "kvm_i386.h" #include "hw/kvm/clock.h" #include "hw/pci-host/q35.h" #include "hw/qdev-properties.h" -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 22/32] hw/i386/pc: Move gsi_state creation code
The block code related to IRQ start few lines later. Move
the comment and the pc_gsi_create() call where we start
to use the IRQs.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc_q35.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 52261962b8..6d096eff28 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -209,9 +209,6 @@ static void pc_q35_init(MachineState *machine)
rom_memory, _memory);
}
-/* irq lines */
-gsi_state = pc_gsi_create(>gsi, pcmc->pci_enabled);
-
/* create pci host bus */
q35_host = Q35_HOST_DEVICE(qdev_create(NULL, TYPE_Q35_HOST_DEVICE));
@@ -245,6 +242,9 @@ static void pc_q35_init(MachineState *machine)
object_property_set_link(OBJECT(machine), OBJECT(lpc),
PC_MACHINE_ACPI_DEVICE_PROP, _abort);
+/* irq lines */
+gsi_state = pc_gsi_create(>gsi, pcmc->pci_enabled);
+
ich9_lpc = ICH9_LPC_DEVICE(lpc);
lpc_dev = DEVICE(lpc);
for (i = 0; i < GSI_NUM_PINS; i++) {
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 20/32] hw/i386/pc: Extract pc_gsi_create()
The GSI creation code is common to all PC machines, extract the
common code.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc.c | 15 +++
hw/i386/pc_piix.c| 9 +
hw/i386/pc_q35.c | 9 +
include/hw/i386/pc.h | 2 ++
4 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index bcda50efcc..a7597c6c44 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -357,6 +357,21 @@ void gsi_handler(void *opaque, int n, int level)
qemu_set_irq(s->ioapic_irq[n], level);
}
+GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
+{
+GSIState *s;
+
+s = g_new0(GSIState, 1);
+if (kvm_ioapic_in_kernel()) {
+kvm_pc_setup_irq_routing(pci_enabled);
+*irqs = qemu_allocate_irqs(kvm_pc_gsi_handler, s, GSI_NUM_PINS);
+} else {
+*irqs = qemu_allocate_irqs(gsi_handler, s, GSI_NUM_PINS);
+}
+
+return s;
+}
+
static void ioport80_write(void *opaque, hwaddr addr, uint64_t data,
unsigned size)
{
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 431965d921..452b107e1b 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -188,14 +188,7 @@ static void pc_init1(MachineState *machine,
xen_load_linux(pcms);
}
-gsi_state = g_malloc0(sizeof(*gsi_state));
-if (kvm_ioapic_in_kernel()) {
-kvm_pc_setup_irq_routing(pcmc->pci_enabled);
-pcms->gsi = qemu_allocate_irqs(kvm_pc_gsi_handler, gsi_state,
- GSI_NUM_PINS);
-} else {
-pcms->gsi = qemu_allocate_irqs(gsi_handler, gsi_state, GSI_NUM_PINS);
-}
+gsi_state = pc_gsi_create(>gsi, pcmc->pci_enabled);
if (pcmc->pci_enabled) {
pci_bus = i440fx_init(host_type,
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 8fad20f314..52261962b8 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -210,14 +210,7 @@ static void pc_q35_init(MachineState *machine)
}
/* irq lines */
-gsi_state = g_malloc0(sizeof(*gsi_state));
-if (kvm_ioapic_in_kernel()) {
-kvm_pc_setup_irq_routing(pcmc->pci_enabled);
-pcms->gsi = qemu_allocate_irqs(kvm_pc_gsi_handler, gsi_state,
- GSI_NUM_PINS);
-} else {
-pcms->gsi = qemu_allocate_irqs(gsi_handler, gsi_state, GSI_NUM_PINS);
-}
+gsi_state = pc_gsi_create(>gsi, pcmc->pci_enabled);
/* create pci host bus */
q35_host = Q35_HOST_DEVICE(qdev_create(NULL, TYPE_Q35_HOST_DEVICE));
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index b63fc7631e..d0c6b9d469 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -174,6 +174,8 @@ typedef struct GSIState {
void gsi_handler(void *opaque, int n, int level);
+GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);
+
/* vmport.c */
#define TYPE_VMPORT "vmport"
typedef uint32_t (VMPortReadFunc)(void *opaque, uint32_t address);
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 21/32] hw/i386/pc: Reduce gsi_handler scope
pc_gsi_create() is the single function that uses gsi_handler.
Make it a static variable.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc.c | 2 +-
include/hw/i386/pc.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a7597c6c44..59de0c8a1f 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -346,7 +346,7 @@ GlobalProperty pc_compat_1_4[] = {
};
const size_t pc_compat_1_4_len = G_N_ELEMENTS(pc_compat_1_4);
-void gsi_handler(void *opaque, int n, int level)
+static void gsi_handler(void *opaque, int n, int level)
{
GSIState *s = opaque;
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index d0c6b9d469..75b44e156c 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -172,8 +172,6 @@ typedef struct GSIState {
qemu_irq ioapic_irq[IOAPIC_NUM_PINS];
} GSIState;
-void gsi_handler(void *opaque, int n, int level);
-
GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);
/* vmport.c */
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 19/32] hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c
From: Philippe Mathieu-Daudé
Now that we properly refactored the piix4_create() function, let's
move it to hw/isa/piix4.c where it belongs, so it can be reused
on other places.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/isa/piix4.c| 30 ++
hw/mips/gt64xxx_pci.c | 1 +
hw/mips/mips_malta.c | 28
include/hw/i386/pc.h | 2 --
include/hw/southbridge/piix.h | 6 ++
5 files changed, 37 insertions(+), 30 deletions(-)
diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index 9f554747af..d90899e122 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -27,12 +27,14 @@
#include "qapi/error.h"
#include "hw/irq.h"
#include "hw/i386/pc.h"
+#include "hw/southbridge/piix.h"
#include "hw/pci/pci.h"
#include "hw/isa/isa.h"
#include "hw/sysbus.h"
#include "hw/dma/i8257.h"
#include "hw/timer/i8254.h"
#include "hw/timer/mc146818rtc.h"
+#include "hw/ide.h"
#include "migration/vmstate.h"
#include "sysemu/reset.h"
#include "sysemu/runstate.h"
@@ -234,3 +236,31 @@ static void piix4_register_types(void)
}
type_init(piix4_register_types)
+
+DeviceState *piix4_create(PCIBus *pci_bus, ISABus **isa_bus,
+ I2CBus **smbus, size_t ide_buses)
+{
+size_t ide_drives = ide_buses * MAX_IDE_DEVS;
+DriveInfo **hd;
+PCIDevice *pci;
+DeviceState *dev;
+
+pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
+ true, TYPE_PIIX4_PCI_DEVICE);
+dev = DEVICE(pci);
+if (isa_bus) {
+*isa_bus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
+}
+
+hd = g_new(DriveInfo *, ide_drives);
+ide_drive_get(hd, ide_drives);
+pci_piix4_ide_init(pci_bus, hd, pci->devfn + 1);
+g_free(hd);
+pci_create_simple(pci_bus, pci->devfn + 2, "piix4-usb-uhci");
+if (smbus) {
+*smbus = piix4_pm_init(pci_bus, pci->devfn + 3, 0x1100,
+ isa_get_irq(NULL, 9), NULL, 0, NULL);
+ }
+
+return dev;
+}
diff --git a/hw/mips/gt64xxx_pci.c b/hw/mips/gt64xxx_pci.c
index f325bd6c1c..c277398c0d 100644
--- a/hw/mips/gt64xxx_pci.c
+++ b/hw/mips/gt64xxx_pci.c
@@ -28,6 +28,7 @@
#include "hw/mips/mips.h"
#include "hw/pci/pci.h"
#include "hw/pci/pci_host.h"
+#include "hw/southbridge/piix.h"
#include "migration/vmstate.h"
#include "hw/i386/pc.h"
#include "hw/irq.h"
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index 0d4312840b..477a4725c0 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -1210,34 +1210,6 @@ static void mips_create_cpu(MachineState *ms, MaltaState
*s,
}
}
-static DeviceState *piix4_create(PCIBus *pci_bus, ISABus **isa_bus,
- I2CBus **smbus, size_t ide_buses)
-{
-const size_t ide_drives = ide_buses * MAX_IDE_DEVS;
-DriveInfo **hd;
-PCIDevice *pci;
-DeviceState *dev;
-
-pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
- true, TYPE_PIIX4_PCI_DEVICE);
-dev = DEVICE(pci);
-if (isa_bus) {
-*isa_bus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
-}
-
-hd = g_new(DriveInfo *, ide_drives);
-ide_drive_get(hd, ide_drives);
-pci_piix4_ide_init(pci_bus, hd, pci->devfn + 1);
-g_free(hd);
-pci_create_simple(pci_bus, pci->devfn + 2, "piix4-usb-uhci");
-if (smbus) {
-*smbus = piix4_pm_init(pci_bus, pci->devfn + 3, 0x1100,
- isa_get_irq(NULL, 9), NULL, 0, NULL);
- }
-
-return dev;
-}
-
static
void mips_malta_init(MachineState *machine)
{
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index c671c9fd2a..b63fc7631e 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -274,8 +274,6 @@ PCIBus *i440fx_init(const char *host_type, const char
*pci_type,
MemoryRegion *ram_memory);
PCIBus *find_i440fx(void);
-/* piix4.c */
-extern PCIDevice *piix4_dev;
/* pc_sysfw.c */
void pc_system_flash_create(PCMachineState *pcms);
diff --git a/include/hw/southbridge/piix.h b/include/hw/southbridge/piix.h
index b8ce26fec4..add352456b 100644
--- a/include/hw/southbridge/piix.h
+++ b/include/hw/southbridge/piix.h
@@ -2,6 +2,7 @@
* QEMU PIIX South Bridge Emulation
*
* Copyright (c) 2006 Fabrice Bellard
+ * Copyright (c) 2018 Hervé Poussineau
*
* This work is licensed under the terms of the GNU GPL, version 2 or later.
* See the COPYING file in the top-level directory.
@@ -17,4 +18,9 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t
smb_io_base,
qemu_irq sci_irq, qemu_irq smi_irq,
int smm_enabled, DeviceState **piix4_pm);
+extern PCIDevice *piix4_dev;
+
+DeviceState *piix4_create(PCIBus *pci_bus, ISABus **isa_bus,
+ I2CBus **smbus, size_t ide_buses);
+
#endif
--
2.21.0
___
Xen-devel mailing list
[Xen-devel] [PATCH 18/32] hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create()
The Malta board instantiate a PIIX4 chipset doing various
calls. Refactor all those related calls into a single
function: piix4_create().
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/mips_malta.c | 47 +++-
1 file changed, 29 insertions(+), 18 deletions(-)
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index 774bb810f6..0d4312840b 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -1210,6 +1210,34 @@ static void mips_create_cpu(MachineState *ms, MaltaState
*s,
}
}
+static DeviceState *piix4_create(PCIBus *pci_bus, ISABus **isa_bus,
+ I2CBus **smbus, size_t ide_buses)
+{
+const size_t ide_drives = ide_buses * MAX_IDE_DEVS;
+DriveInfo **hd;
+PCIDevice *pci;
+DeviceState *dev;
+
+pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
+ true, TYPE_PIIX4_PCI_DEVICE);
+dev = DEVICE(pci);
+if (isa_bus) {
+*isa_bus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
+}
+
+hd = g_new(DriveInfo *, ide_drives);
+ide_drive_get(hd, ide_drives);
+pci_piix4_ide_init(pci_bus, hd, pci->devfn + 1);
+g_free(hd);
+pci_create_simple(pci_bus, pci->devfn + 2, "piix4-usb-uhci");
+if (smbus) {
+*smbus = piix4_pm_init(pci_bus, pci->devfn + 3, 0x1100,
+ isa_get_irq(NULL, 9), NULL, 0, NULL);
+ }
+
+return dev;
+}
+
static
void mips_malta_init(MachineState *machine)
{
@@ -1231,12 +1259,8 @@ void mips_malta_init(MachineState *machine)
PCIBus *pci_bus;
ISABus *isa_bus;
qemu_irq cbus_irq, i8259_irq;
-PCIDevice *pci;
-int piix4_devfn;
I2CBus *smbus;
DriveInfo *dinfo;
-const size_t ide_drives = MAX_IDE_BUS * MAX_IDE_DEVS;
-DriveInfo **hd;
int fl_idx = 0;
int be;
@@ -1407,14 +1431,7 @@ void mips_malta_init(MachineState *machine)
pci_bus = gt64120_register(s->i8259);
/* Southbridge */
-hd = g_new(DriveInfo *, ide_drives);
-ide_drive_get(hd, ide_drives);
-
-pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
- true, TYPE_PIIX4_PCI_DEVICE);
-dev = DEVICE(pci);
-isa_bus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
-piix4_devfn = pci->devfn;
+dev = piix4_create(pci_bus, _bus, , MAX_IDE_BUS);
/* Interrupt controller */
qdev_connect_gpio_out_named(dev, "intr", 0, i8259_irq);
@@ -1422,12 +1439,6 @@ void mips_malta_init(MachineState *machine)
s->i8259[i] = qdev_get_gpio_in_named(dev, "isa", i);
}
-pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1);
-g_free(hd);
-pci_create_simple(pci_bus, piix4_devfn + 2, "piix4-usb-uhci");
-smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
- isa_get_irq(NULL, 9), NULL, 0, NULL);
-
/* generate SPD EEPROM data */
generate_eeprom_spd(_eeprom_buf[0 * 256], ram_size);
generate_eeprom_serial(_eeprom_buf[6 * 256]);
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 17/32] hw/mips/mips_malta: Create IDE hard drive array dynamically
In the next commit we'll refactor the PIIX4 code out of mips_malta_init(). As a preliminary step, add the 'ide_drives' variable and create the drive array dynamically. Signed-off-by: Philippe Mathieu-Daudé --- hw/mips/mips_malta.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c index 528c34a1c3..774bb810f6 100644 --- a/hw/mips/mips_malta.c +++ b/hw/mips/mips_malta.c @@ -1235,7 +1235,8 @@ void mips_malta_init(MachineState *machine) int piix4_devfn; I2CBus *smbus; DriveInfo *dinfo; -DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS]; +const size_t ide_drives = MAX_IDE_BUS * MAX_IDE_DEVS; +DriveInfo **hd; int fl_idx = 0; int be; @@ -1406,7 +1407,8 @@ void mips_malta_init(MachineState *machine) pci_bus = gt64120_register(s->i8259); /* Southbridge */ -ide_drive_get(hd, ARRAY_SIZE(hd)); +hd = g_new(DriveInfo *, ide_drives); +ide_drive_get(hd, ide_drives); pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0), true, TYPE_PIIX4_PCI_DEVICE); @@ -1421,6 +1423,7 @@ void mips_malta_init(MachineState *machine) } pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1); +g_free(hd); pci_create_simple(pci_bus, piix4_devfn + 2, "piix4-usb-uhci"); smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100, isa_get_irq(NULL, 9), NULL, 0, NULL); -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 16/32] piix4: add a mc146818rtc controller as specified in datasheet
From: Philippe Mathieu-Daudé
Remove mc146818rtc instanciated in malta board, to not have it twice.
Acked-by: Michael S. Tsirkin
Acked-by: Paolo Bonzini
Signed-off-by: Hervé Poussineau
Message-Id: <20171216090228.28505-13-hpous...@reactos.org>
[PMD: rebased, set RTC base_year to 2000]
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 3 ++-
hw/acpi/piix4.c | 2 +-
hw/i386/acpi-build.c | 3 +--
hw/i386/pc_piix.c | 1 +
hw/isa/piix4.c| 22 ++
hw/mips/mips_malta.c | 4 +---
include/hw/acpi/piix4.h | 6 --
include/hw/i386/pc.h | 6 --
include/hw/southbridge/piix.h | 20
9 files changed, 48 insertions(+), 19 deletions(-)
delete mode 100644 include/hw/acpi/piix4.h
create mode 100644 include/hw/southbridge/piix.h
diff --git a/MAINTAINERS b/MAINTAINERS
index c9f625fc2e..556f58bd8c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1235,7 +1235,7 @@ F: hw/i2c/smbus_ich9.c
F: hw/acpi/piix4.c
F: hw/acpi/ich9.c
F: include/hw/acpi/ich9.h
-F: include/hw/acpi/piix4.h
+F: include/hw/southbridge/piix.h
F: hw/misc/sga.c
F: hw/isa/apm.c
F: include/hw/isa/apm.h
@@ -1720,6 +1720,7 @@ M: Hervé Poussineau
M: Philippe Mathieu-Daudé
S: Maintained
F: hw/isa/piix4.c
+F: include/hw/southbridge/piix.h
Firmware configuration (fw_cfg)
M: Philippe Mathieu-Daudé
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 1d29d438c7..27270621ab 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -21,6 +21,7 @@
#include "qemu/osdep.h"
#include "hw/i386/pc.h"
+#include "hw/southbridge/piix.h"
#include "hw/irq.h"
#include "hw/isa/apm.h"
#include "hw/i2c/pm_smbus.h"
@@ -33,7 +34,6 @@
#include "qapi/error.h"
#include "qemu/range.h"
#include "exec/address-spaces.h"
-#include "hw/acpi/piix4.h"
#include "hw/acpi/pcihp.h"
#include "hw/acpi/cpu_hotplug.h"
#include "hw/acpi/cpu.h"
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 4e0f9f425a..aa6fe61191 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -34,7 +34,6 @@
#include "hw/acpi/acpi-defs.h"
#include "hw/acpi/acpi.h"
#include "hw/acpi/cpu.h"
-#include "hw/acpi/piix4.h"
#include "hw/nvram/fw_cfg.h"
#include "hw/acpi/bios-linker-loader.h"
#include "hw/isa/isa.h"
@@ -52,7 +51,7 @@
#include "sysemu/reset.h"
/* Supported chipsets: */
-#include "hw/acpi/piix4.h"
+#include "hw/southbridge/piix.h"
#include "hw/acpi/pcihp.h"
#include "hw/i386/ich9.h"
#include "hw/pci/pci_bus.h"
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 6824b72124..431965d921 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -29,6 +29,7 @@
#include "hw/loader.h"
#include "hw/i386/pc.h"
#include "hw/i386/apic.h"
+#include "hw/southbridge/piix.h"
#include "hw/display/ramfb.h"
#include "hw/firmware/smbios.h"
#include "hw/pci/pci.h"
diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index 0b0a0ecab1..9f554747af 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -24,6 +24,7 @@
*/
#include "qemu/osdep.h"
+#include "qapi/error.h"
#include "hw/irq.h"
#include "hw/i386/pc.h"
#include "hw/pci/pci.h"
@@ -31,6 +32,7 @@
#include "hw/sysbus.h"
#include "hw/dma/i8257.h"
#include "hw/timer/i8254.h"
+#include "hw/timer/mc146818rtc.h"
#include "migration/vmstate.h"
#include "sysemu/reset.h"
#include "sysemu/runstate.h"
@@ -42,6 +44,7 @@ typedef struct PIIX4State {
qemu_irq cpu_intr;
qemu_irq *isa;
+RTCState rtc;
/* Reset Control Register */
MemoryRegion rcr_mem;
uint8_t rcr;
@@ -144,6 +147,7 @@ static void piix4_realize(PCIDevice *pci_dev, Error **errp)
PIIX4State *s = DO_UPCAST(PIIX4State, dev, pci_dev);
ISABus *isa_bus;
qemu_irq *i8259_out_irq;
+Error *err = NULL;
isa_bus = isa_bus_new(dev, pci_address_space(pci_dev),
pci_address_space_io(pci_dev), errp);
@@ -172,9 +176,26 @@ static void piix4_realize(PCIDevice *pci_dev, Error **errp)
/* DMA */
i8257_dma_init(isa_bus, 0);
+/* RTC */
+qdev_set_parent_bus(DEVICE(>rtc), BUS(isa_bus));
+qdev_prop_set_int32(DEVICE(>rtc), "base_year", 2000);
+object_property_set_bool(OBJECT(>rtc), true, "realized", );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+isa_init_irq(ISA_DEVICE(>rtc), >rtc.irq, RTC_ISA_IRQ);
+
piix4_dev = pci_dev;
}
+static void piix4_init(Object *obj)
+{
+PIIX4State *s = PIIX4_PCI_DEVICE(obj);
+
+object_initialize(>rtc, sizeof(s->rtc), TYPE_MC146818_RTC);
+}
+
static void piix4_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
@@ -199,6 +220,7 @@ static const TypeInfo piix4_info = {
.name = TYPE_PIIX4_PCI_DEVICE,
.parent= TYPE_PCI_DEVICE,
.instance_size = sizeof(PIIX4State),
+.instance_init = piix4_init,
.class_init= piix4_class_init,
.interfaces = (InterfaceInfo[]) {
{
[Xen-devel] [PATCH 15/32] piix4: add a i8254 pit controller as specified in datasheet
From: Hervé Poussineau
Remove i8254 instanciated in malta board, to not have it twice.
Acked-by: Michael S. Tsirkin
Acked-by: Paolo Bonzini
Signed-off-by: Hervé Poussineau
Message-Id: <20171216090228.28505-10-hpous...@reactos.org>
Signed-off-by: Philippe Mathieu-Daudé
---
hw/isa/piix4.c | 4
hw/mips/mips_malta.c | 4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index 1bc91b590c..0b0a0ecab1 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -30,6 +30,7 @@
#include "hw/isa/isa.h"
#include "hw/sysbus.h"
#include "hw/dma/i8257.h"
+#include "hw/timer/i8254.h"
#include "migration/vmstate.h"
#include "sysemu/reset.h"
#include "sysemu/runstate.h"
@@ -165,6 +166,9 @@ static void piix4_realize(PCIDevice *pci_dev, Error **errp)
/* initialize ISA irqs */
isa_bus_irqs(isa_bus, s->isa);
+/* initialize pit */
+i8254_pit_init(isa_bus, 0x40, 0, NULL);
+
/* DMA */
i8257_dma_init(isa_bus, 0);
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index df247177ca..16d7a0e785 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -45,7 +45,6 @@
#include "hw/loader.h"
#include "elf.h"
#include "hw/timer/mc146818rtc.h"
-#include "hw/timer/i8254.h"
#include "exec/address-spaces.h"
#include "hw/sysbus.h" /* SysBusDevice */
#include "qemu/host-utils.h"
@@ -99,8 +98,6 @@ typedef struct {
qemu_irq i8259[16];
} MaltaState;
-static ISADevice *pit;
-
static struct _loaderparams {
int ram_size, ram_low_size;
const char *kernel_filename;
@@ -1428,7 +1425,6 @@ void mips_malta_init(MachineState *machine)
pci_create_simple(pci_bus, piix4_devfn + 2, "piix4-usb-uhci");
smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
isa_get_irq(NULL, 9), NULL, 0, NULL);
-pit = i8254_pit_init(isa_bus, 0x40, 0, NULL);
mc146818_rtc_init(isa_bus, 2000, NULL);
/* generate SPD EEPROM data */
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 14/32] piix4: add a i8257 dma controller as specified in datasheet
From: Hervé Poussineau Remove i8257 instanciated in malta board, to not have it twice. Acked-by: Michael S. Tsirkin Acked-by: Paolo Bonzini Signed-off-by: Hervé Poussineau Message-Id: <20171216090228.28505-9-hpous...@reactos.org> [PMD: rebased] Signed-off-by: Philippe Mathieu-Daudé --- hw/isa/piix4.c | 4 hw/mips/mips_malta.c | 2 -- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c index 8998b0ca47..1bc91b590c 100644 --- a/hw/isa/piix4.c +++ b/hw/isa/piix4.c @@ -29,6 +29,7 @@ #include "hw/pci/pci.h" #include "hw/isa/isa.h" #include "hw/sysbus.h" +#include "hw/dma/i8257.h" #include "migration/vmstate.h" #include "sysemu/reset.h" #include "sysemu/runstate.h" @@ -164,6 +165,9 @@ static void piix4_realize(PCIDevice *pci_dev, Error **errp) /* initialize ISA irqs */ isa_bus_irqs(isa_bus, s->isa); +/* DMA */ +i8257_dma_init(isa_bus, 0); + piix4_dev = pci_dev; } diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c index e499b7a6bb..df247177ca 100644 --- a/hw/mips/mips_malta.c +++ b/hw/mips/mips_malta.c @@ -28,7 +28,6 @@ #include "cpu.h" #include "hw/i386/pc.h" #include "hw/isa/superio.h" -#include "hw/dma/i8257.h" #include "hw/char/serial.h" #include "net/net.h" #include "hw/boards.h" @@ -1430,7 +1429,6 @@ void mips_malta_init(MachineState *machine) smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100, isa_get_irq(NULL, 9), NULL, 0, NULL); pit = i8254_pit_init(isa_bus, 0x40, 0, NULL); -i8257_dma_init(isa_bus, 0); mc146818_rtc_init(isa_bus, 2000, NULL); /* generate SPD EEPROM data */ -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 01/32] hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers
I forgot to Cc David and Daniel for this one.
On 10/15/19 6:26 PM, Philippe Mathieu-Daudé wrote:
These devices implemented their load_state_old() handler 10 years
ago, previous to QEMU v0.12.
Since commit cc425b5ddf removed the pc-0.10 and pc-0.11 machines,
we can drop this code.
Note: the mips_r4k machine started to use the i8254 device just
after QEMU v0.5.0, but the MIPS machine types are not versioned,
so there is no migration compatibility issue removing this handler.
Suggested-by: Peter Maydell
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/piix4.c | 40 -
hw/intc/apic_common.c | 49 -
hw/pci-host/piix.c | 25 -
hw/timer/i8254_common.c | 40 -
4 files changed, 154 deletions(-)
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 5742c3df87..1d29d438c7 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -42,7 +42,6 @@
#include "hw/acpi/memory_hotplug.h"
#include "hw/acpi/acpi_dev_interface.h"
#include "hw/xen/xen.h"
-#include "migration/qemu-file-types.h"
#include "migration/vmstate.h"
#include "hw/core/cpu.h"
#include "trace.h"
@@ -205,43 +204,6 @@ static const VMStateDescription vmstate_pci_status = {
}
};
-static int acpi_load_old(QEMUFile *f, void *opaque, int version_id)
-{
-PIIX4PMState *s = opaque;
-int ret, i;
-uint16_t temp;
-
-ret = pci_device_load(PCI_DEVICE(s), f);
-if (ret < 0) {
-return ret;
-}
-qemu_get_be16s(f, >ar.pm1.evt.sts);
-qemu_get_be16s(f, >ar.pm1.evt.en);
-qemu_get_be16s(f, >ar.pm1.cnt.cnt);
-
-ret = vmstate_load_state(f, _apm, >apm, 1);
-if (ret) {
-return ret;
-}
-
-timer_get(f, s->ar.tmr.timer);
-qemu_get_sbe64s(f, >ar.tmr.overflow_time);
-
-qemu_get_be16s(f, (uint16_t *)s->ar.gpe.sts);
-for (i = 0; i < 3; i++) {
-qemu_get_be16s(f, );
-}
-
-qemu_get_be16s(f, (uint16_t *)s->ar.gpe.en);
-for (i = 0; i < 3; i++) {
-qemu_get_be16s(f, );
-}
-
-ret = vmstate_load_state(f, _pci_status,
->acpi_pci_hotplug.acpi_pcihp_pci_status[ACPI_PCIHP_BSEL_DEFAULT],
1);
-return ret;
-}
-
static bool vmstate_test_use_acpi_pci_hotplug(void *opaque, int version_id)
{
PIIX4PMState *s = opaque;
@@ -313,8 +275,6 @@ static const VMStateDescription vmstate_acpi = {
.name = "piix4_pm",
.version_id = 3,
.minimum_version_id = 3,
-.minimum_version_id_old = 1,
-.load_state_old = acpi_load_old,
.post_load = vmstate_acpi_post_load,
.fields = (VMStateField[]) {
VMSTATE_PCI_DEVICE(parent_obj, PIIX4PMState),
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index aafd8e0e33..375cb6abe9 100644
--- a/hw/intc/apic_common.c
+++ b/hw/intc/apic_common.c
@@ -31,7 +31,6 @@
#include "sysemu/kvm.h"
#include "hw/qdev-properties.h"
#include "hw/sysbus.h"
-#include "migration/qemu-file-types.h"
#include "migration/vmstate.h"
static int apic_irq_delivered;
@@ -262,52 +261,6 @@ static void apic_reset_common(DeviceState *dev)
apic_init_reset(dev);
}
-/* This function is only used for old state version 1 and 2 */
-static int apic_load_old(QEMUFile *f, void *opaque, int version_id)
-{
-APICCommonState *s = opaque;
-APICCommonClass *info = APIC_COMMON_GET_CLASS(s);
-int i;
-
-if (version_id > 2) {
-return -EINVAL;
-}
-
-/* XXX: what if the base changes? (registered memory regions) */
-qemu_get_be32s(f, >apicbase);
-qemu_get_8s(f, >id);
-qemu_get_8s(f, >arb_id);
-qemu_get_8s(f, >tpr);
-qemu_get_be32s(f, >spurious_vec);
-qemu_get_8s(f, >log_dest);
-qemu_get_8s(f, >dest_mode);
-for (i = 0; i < 8; i++) {
-qemu_get_be32s(f, >isr[i]);
-qemu_get_be32s(f, >tmr[i]);
-qemu_get_be32s(f, >irr[i]);
-}
-for (i = 0; i < APIC_LVT_NB; i++) {
-qemu_get_be32s(f, >lvt[i]);
-}
-qemu_get_be32s(f, >esr);
-qemu_get_be32s(f, >icr[0]);
-qemu_get_be32s(f, >icr[1]);
-qemu_get_be32s(f, >divide_conf);
-s->count_shift = qemu_get_be32(f);
-qemu_get_be32s(f, >initial_count);
-s->initial_count_load_time = qemu_get_be64(f);
-s->next_time = qemu_get_be64(f);
-
-if (version_id >= 2) {
-s->timer_expiry = qemu_get_be64(f);
-}
-
-if (info->post_load) {
-info->post_load(s);
-}
-return 0;
-}
-
static const VMStateDescription vmstate_apic_common;
static void apic_common_realize(DeviceState *dev, Error **errp)
@@ -408,8 +361,6 @@ static const VMStateDescription vmstate_apic_common = {
.name = "apic",
.version_id = 3,
.minimum_version_id = 3,
-.minimum_version_id_old = 1,
-.load_state_old = apic_load_old,
.pre_load = apic_pre_load,
.pre_save = apic_dispatch_pre_save,
.post_load = apic_dispatch_post_load,
diff --git a/hw/pci-host/piix.c
[Xen-devel] [PATCH 13/32] piix4: convert reset function to QOM
From: Hervé Poussineau
Acked-by: Michael S. Tsirkin
Acked-by: Paolo Bonzini
Signed-off-by: Hervé Poussineau
Message-Id: <20180106153730.30313-15-hpous...@reactos.org>
Signed-off-by: Philippe Mathieu-Daudé
---
hw/isa/piix4.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index c3a2bd0d70..8998b0ca47 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -48,10 +48,10 @@ typedef struct PIIX4State {
#define PIIX4_PCI_DEVICE(obj) \
OBJECT_CHECK(PIIX4State, (obj), TYPE_PIIX4_PCI_DEVICE)
-static void piix4_reset(void *opaque)
+static void piix4_reset(DeviceState *dev)
{
-PIIX4State *d = opaque;
-uint8_t *pci_conf = d->dev.config;
+PIIX4State *s = PIIX4_PCI_DEVICE(dev);
+uint8_t *pci_conf = s->dev.config;
pci_conf[0x04] = 0x07; // master, memory and I/O
pci_conf[0x05] = 0x00;
@@ -165,7 +165,6 @@ static void piix4_realize(PCIDevice *pci_dev, Error **errp)
isa_bus_irqs(isa_bus, s->isa);
piix4_dev = pci_dev;
-qemu_register_reset(piix4_reset, s);
}
static void piix4_class_init(ObjectClass *klass, void *data)
@@ -177,6 +176,7 @@ static void piix4_class_init(ObjectClass *klass, void *data)
k->vendor_id = PCI_VENDOR_ID_INTEL;
k->device_id = PCI_DEVICE_ID_INTEL_82371AB_0;
k->class_id = PCI_CLASS_BRIDGE_ISA;
+dc->reset = piix4_reset;
dc->desc = "ISA bridge";
dc->vmsd = _piix4;
/*
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 12/32] piix4: rename PIIX4 object to piix4-isa
From: Hervé Poussineau
Other piix4 parts are already named piix4-ide and piix4-usb-uhci.
Reviewed-by: Philippe Mathieu-Daudé
Acked-by: Michael S. Tsirkin
Acked-by: Paolo Bonzini
Signed-off-by: Hervé Poussineau
Message-Id: <20171216090228.28505-15-hpous...@reactos.org>
[PMD: rebased]
Signed-off-by: Philippe Mathieu-Daudé
---
hw/isa/piix4.c | 1 -
hw/mips/mips_malta.c | 2 +-
include/hw/isa/isa.h | 2 ++
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index 1cfc51335a..c3a2bd0d70 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -45,7 +45,6 @@ typedef struct PIIX4State {
uint8_t rcr;
} PIIX4State;
-#define TYPE_PIIX4_PCI_DEVICE "PIIX4"
#define PIIX4_PCI_DEVICE(obj) \
OBJECT_CHECK(PIIX4State, (obj), TYPE_PIIX4_PCI_DEVICE)
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index 7d25ab6c23..e499b7a6bb 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -1414,7 +1414,7 @@ void mips_malta_init(MachineState *machine)
ide_drive_get(hd, ARRAY_SIZE(hd));
pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
- true, "PIIX4");
+ true, TYPE_PIIX4_PCI_DEVICE);
dev = DEVICE(pci);
isa_bus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
piix4_devfn = pci->devfn;
diff --git a/include/hw/isa/isa.h b/include/hw/isa/isa.h
index 018ada4f6f..79f703fd6c 100644
--- a/include/hw/isa/isa.h
+++ b/include/hw/isa/isa.h
@@ -147,4 +147,6 @@ static inline ISABus *isa_bus_from_device(ISADevice *d)
return ISA_BUS(qdev_get_parent_bus(DEVICE(d)));
}
+#define TYPE_PIIX4_PCI_DEVICE "piix4-isa"
+
#endif
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 11/32] Revert "irq: introduce qemu_irq_proxy()"
From: Philippe Mathieu-Daudé
This function isn't used anymore.
This reverts commit 22ec3283efba9ba0792790da786d6776d83f2a92.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/core/irq.c| 14 --
include/hw/irq.h | 5 -
2 files changed, 19 deletions(-)
diff --git a/hw/core/irq.c b/hw/core/irq.c
index 7cc0295d0e..fb3045b912 100644
--- a/hw/core/irq.c
+++ b/hw/core/irq.c
@@ -120,20 +120,6 @@ qemu_irq qemu_irq_split(qemu_irq irq1, qemu_irq irq2)
return qemu_allocate_irq(qemu_splitirq, s, 0);
}
-static void proxy_irq_handler(void *opaque, int n, int level)
-{
-qemu_irq **target = opaque;
-
-if (*target) {
-qemu_set_irq((*target)[n], level);
-}
-}
-
-qemu_irq *qemu_irq_proxy(qemu_irq **target, int n)
-{
-return qemu_allocate_irqs(proxy_irq_handler, target, n);
-}
-
void qemu_irq_intercept_in(qemu_irq *gpio_in, qemu_irq_handler handler, int n)
{
int i;
diff --git a/include/hw/irq.h b/include/hw/irq.h
index fe527f6f51..24ba0ece11 100644
--- a/include/hw/irq.h
+++ b/include/hw/irq.h
@@ -51,11 +51,6 @@ qemu_irq qemu_irq_invert(qemu_irq irq);
*/
qemu_irq qemu_irq_split(qemu_irq irq1, qemu_irq irq2);
-/* Returns a new IRQ set which connects 1:1 to another IRQ set, which
- * may be set later.
- */
-qemu_irq *qemu_irq_proxy(qemu_irq **target, int n);
-
/* For internal use in qtest. Similar to qemu_irq_split, but operating
on an existing vector of qemu_irq. */
void qemu_irq_intercept_in(qemu_irq *gpio_in, qemu_irq_handler handler, int n);
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 09/32] piix4: add Reset Control Register
From: Hervé Poussineau
The RCR I/O port (0xcf9) is used to generate a hard reset or a soft reset.
Acked-by: Michael S. Tsirkin
Acked-by: Paolo Bonzini
Signed-off-by: Hervé Poussineau
Message-Id: <20171216090228.28505-7-hpous...@reactos.org>
[PMD: rebased, updated includes]
Signed-off-by: Philippe Mathieu-Daudé
---
hw/isa/piix4.c | 40
1 file changed, 40 insertions(+)
diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index 4202243e41..6e2d9b9774 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -2,6 +2,7 @@
* QEMU PIIX4 PCI Bridge Emulation
*
* Copyright (c) 2006 Fabrice Bellard
+ * Copyright (c) 2018 Hervé Poussineau
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
deal
@@ -29,11 +30,16 @@
#include "hw/sysbus.h"
#include "migration/vmstate.h"
#include "sysemu/reset.h"
+#include "sysemu/runstate.h"
PCIDevice *piix4_dev;
typedef struct PIIX4State {
PCIDevice dev;
+
+/* Reset Control Register */
+MemoryRegion rcr_mem;
+uint8_t rcr;
} PIIX4State;
#define TYPE_PIIX4_PCI_DEVICE "PIIX4"
@@ -88,6 +94,34 @@ static const VMStateDescription vmstate_piix4 = {
}
};
+static void piix4_rcr_write(void *opaque, hwaddr addr, uint64_t val,
+unsigned int len)
+{
+PIIX4State *s = opaque;
+
+if (val & 4) {
+qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
+return;
+}
+s->rcr = val & 2; /* keep System Reset type only */
+}
+
+static uint64_t piix4_rcr_read(void *opaque, hwaddr addr, unsigned int len)
+{
+PIIX4State *s = opaque;
+return s->rcr;
+}
+
+static const MemoryRegionOps piix4_rcr_ops = {
+.read = piix4_rcr_read,
+.write = piix4_rcr_write,
+.endianness = DEVICE_LITTLE_ENDIAN,
+.impl = {
+.min_access_size = 1,
+.max_access_size = 1,
+},
+};
+
static void piix4_realize(PCIDevice *pci_dev, Error **errp)
{
DeviceState *dev = DEVICE(pci_dev);
@@ -97,6 +131,12 @@ static void piix4_realize(PCIDevice *pci_dev, Error **errp)
pci_address_space_io(pci_dev), errp)) {
return;
}
+
+memory_region_init_io(>rcr_mem, OBJECT(dev), _rcr_ops, s,
+ "reset-control", 1);
+memory_region_add_subregion_overlap(pci_address_space_io(pci_dev), 0xcf9,
+>rcr_mem, 1);
+
piix4_dev = pci_dev;
qemu_register_reset(piix4_reset, s);
}
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 10/32] piix4: add a i8259 interrupt controller as specified in datasheet
From: Hervé Poussineau
Add ISA irqs as piix4 gpio in, and CPU interrupt request as piix4 gpio out.
Remove i8259 instanciated in malta board, to not have it twice.
We can also remove the now unused piix4_init() function.
Acked-by: Michael S. Tsirkin
Acked-by: Paolo Bonzini
Signed-off-by: Hervé Poussineau
Message-Id: <20171216090228.28505-8-hpous...@reactos.org>
[PMD: rebased, updated includes, use ISA_NUM_IRQS in for loop]
Signed-off-by: Philippe Mathieu-Daudé
---
hw/isa/piix4.c | 41 ++---
hw/mips/mips_malta.c | 32 +---
include/hw/i386/pc.h | 1 -
3 files changed, 43 insertions(+), 31 deletions(-)
diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index 6e2d9b9774..1cfc51335a 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -24,6 +24,7 @@
*/
#include "qemu/osdep.h"
+#include "hw/irq.h"
#include "hw/i386/pc.h"
#include "hw/pci/pci.h"
#include "hw/isa/isa.h"
@@ -36,6 +37,8 @@ PCIDevice *piix4_dev;
typedef struct PIIX4State {
PCIDevice dev;
+qemu_irq cpu_intr;
+qemu_irq *isa;
/* Reset Control Register */
MemoryRegion rcr_mem;
@@ -94,6 +97,18 @@ static const VMStateDescription vmstate_piix4 = {
}
};
+static void piix4_request_i8259_irq(void *opaque, int irq, int level)
+{
+PIIX4State *s = opaque;
+qemu_set_irq(s->cpu_intr, level);
+}
+
+static void piix4_set_i8259_irq(void *opaque, int irq, int level)
+{
+PIIX4State *s = opaque;
+qemu_set_irq(s->isa[irq], level);
+}
+
static void piix4_rcr_write(void *opaque, hwaddr addr, uint64_t val,
unsigned int len)
{
@@ -126,30 +141,34 @@ static void piix4_realize(PCIDevice *pci_dev, Error
**errp)
{
DeviceState *dev = DEVICE(pci_dev);
PIIX4State *s = DO_UPCAST(PIIX4State, dev, pci_dev);
+ISABus *isa_bus;
+qemu_irq *i8259_out_irq;
-if (!isa_bus_new(dev, pci_address_space(pci_dev),
- pci_address_space_io(pci_dev), errp)) {
+isa_bus = isa_bus_new(dev, pci_address_space(pci_dev),
+ pci_address_space_io(pci_dev), errp);
+if (!isa_bus) {
return;
}
+qdev_init_gpio_in_named(dev, piix4_set_i8259_irq, "isa", ISA_NUM_IRQS);
+qdev_init_gpio_out_named(dev, >cpu_intr, "intr", 1);
+
memory_region_init_io(>rcr_mem, OBJECT(dev), _rcr_ops, s,
"reset-control", 1);
memory_region_add_subregion_overlap(pci_address_space_io(pci_dev), 0xcf9,
>rcr_mem, 1);
+/* initialize i8259 pic */
+i8259_out_irq = qemu_allocate_irqs(piix4_request_i8259_irq, s, 1);
+s->isa = i8259_init(isa_bus, *i8259_out_irq);
+
+/* initialize ISA irqs */
+isa_bus_irqs(isa_bus, s->isa);
+
piix4_dev = pci_dev;
qemu_register_reset(piix4_reset, s);
}
-int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn)
-{
-PCIDevice *d;
-
-d = pci_create_simple_multifunction(bus, devfn, true, "PIIX4");
-*isa_bus = ISA_BUS(qdev_get_child_bus(DEVICE(d), "isa.0"));
-return d->devfn;
-}
-
static void piix4_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index 4d9c64b36a..7d25ab6c23 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -97,7 +97,7 @@ typedef struct {
SysBusDevice parent_obj;
MIPSCPSState cps;
-qemu_irq *i8259;
+qemu_irq i8259[16];
} MaltaState;
static ISADevice *pit;
@@ -1235,8 +1235,8 @@ void mips_malta_init(MachineState *machine)
int64_t kernel_entry, bootloader_run_addr;
PCIBus *pci_bus;
ISABus *isa_bus;
-qemu_irq *isa_irq;
qemu_irq cbus_irq, i8259_irq;
+PCIDevice *pci;
int piix4_devfn;
I2CBus *smbus;
DriveInfo *dinfo;
@@ -1407,30 +1407,24 @@ void mips_malta_init(MachineState *machine)
/* Board ID = 0x420 (Malta Board with CoreLV) */
stl_p(memory_region_get_ram_ptr(bios_copy) + 0x10, 0x0420);
-/*
- * We have a circular dependency problem: pci_bus depends on isa_irq,
- * isa_irq is provided by i8259, i8259 depends on ISA, ISA depends
- * on piix4, and piix4 depends on pci_bus. To stop the cycle we have
- * qemu_irq_proxy() adds an extra bit of indirection, allowing us
- * to resolve the isa_irq -> i8259 dependency after i8259 is initialized.
- */
-isa_irq = qemu_irq_proxy(>i8259, 16);
-
/* Northbridge */
-pci_bus = gt64120_register(isa_irq);
+pci_bus = gt64120_register(s->i8259);
/* Southbridge */
ide_drive_get(hd, ARRAY_SIZE(hd));
-piix4_devfn = piix4_init(pci_bus, _bus, 80);
+pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
+ true, "PIIX4");
+dev = DEVICE(pci);
+isa_bus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
+piix4_devfn = pci->devfn;
-/*
- * Interrupt controller
- * The 8259 is attached
[Xen-devel] [PATCH 08/32] piix4: rename some variables in realize function
From: Hervé Poussineau
PIIX4 structure is now 's'
PCI device is now 'pci_dev'
DeviceState is now 'dev'
Acked-by: Michael S. Tsirkin
Acked-by: Paolo Bonzini
Signed-off-by: Hervé Poussineau
Message-Id: <20171216090228.28505-6-hpous...@reactos.org>
Signed-off-by: Philippe Mathieu-Daudé
---
hw/isa/piix4.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index 3294056cd5..4202243e41 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -88,16 +88,17 @@ static const VMStateDescription vmstate_piix4 = {
}
};
-static void piix4_realize(PCIDevice *dev, Error **errp)
+static void piix4_realize(PCIDevice *pci_dev, Error **errp)
{
-PIIX4State *d = PIIX4_PCI_DEVICE(dev);
+DeviceState *dev = DEVICE(pci_dev);
+PIIX4State *s = DO_UPCAST(PIIX4State, dev, pci_dev);
-if (!isa_bus_new(DEVICE(d), pci_address_space(dev),
- pci_address_space_io(dev), errp)) {
+if (!isa_bus_new(dev, pci_address_space(pci_dev),
+ pci_address_space_io(pci_dev), errp)) {
return;
}
-piix4_dev = >dev;
-qemu_register_reset(piix4_reset, d);
+piix4_dev = pci_dev;
+qemu_register_reset(piix4_reset, s);
}
int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn)
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 04/32] mc146818rtc: Move RTC_ISA_IRQ definition
From: Philippe Mathieu-Daudé
The ISA default number for the RTC devices is not related to its
registers neither. Move this definition to "hw/timer/mc146818rtc.h".
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/timer/mc146818rtc.h | 2 ++
include/hw/timer/mc146818rtc_regs.h | 2 --
tests/rtc-test.c| 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/hw/timer/mc146818rtc.h b/include/hw/timer/mc146818rtc.h
index 0f1c886e5b..17761cf6d9 100644
--- a/include/hw/timer/mc146818rtc.h
+++ b/include/hw/timer/mc146818rtc.h
@@ -39,6 +39,8 @@ typedef struct RTCState {
QLIST_ENTRY(RTCState) link;
} RTCState;
+#define RTC_ISA_IRQ 8
+
ISADevice *mc146818_rtc_init(ISABus *bus, int base_year,
qemu_irq intercept_irq);
void rtc_set_memory(ISADevice *dev, int addr, int val);
diff --git a/include/hw/timer/mc146818rtc_regs.h
b/include/hw/timer/mc146818rtc_regs.h
index bfbb57e570..631f71cfd9 100644
--- a/include/hw/timer/mc146818rtc_regs.h
+++ b/include/hw/timer/mc146818rtc_regs.h
@@ -27,8 +27,6 @@
#include "qemu/timer.h"
-#define RTC_ISA_IRQ 8
-
#define RTC_SECONDS 0
#define RTC_SECONDS_ALARM 1
#define RTC_MINUTES 2
diff --git a/tests/rtc-test.c b/tests/rtc-test.c
index 6309b0ef6c..18f895690f 100644
--- a/tests/rtc-test.c
+++ b/tests/rtc-test.c
@@ -15,6 +15,7 @@
#include "libqtest-single.h"
#include "qemu/timer.h"
+#include "hw/timer/mc146818rtc.h"
#include "hw/timer/mc146818rtc_regs.h"
#define UIP_HOLD_LENGTH (8 * NANOSECONDS_PER_SECOND / 32768)
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 05/32] mc146818rtc: Include "mc146818rtc_regs.h" directly in mc146818rtc.c
From: Philippe Mathieu-Daudé Devices/boards wanting to use the MC146818 RTC don't need the knowledge its internal registers. Move the "mc146818rtc_regs.h" inclusion to mc146818rtc.c where it is required. We can not move this file from include/hw/timer/ to hw/timer/ for local inclusion because the ACPI FADT table use the RTC_CENTURY register address. Signed-off-by: Philippe Mathieu-Daudé --- hw/timer/mc146818rtc.c | 1 + include/hw/timer/mc146818rtc.h | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c index e40b54e743..0c04b74c2e 100644 --- a/hw/timer/mc146818rtc.c +++ b/hw/timer/mc146818rtc.c @@ -41,6 +41,7 @@ #include "qapi/qapi-events-misc-target.h" #include "qapi/visitor.h" #include "exec/address-spaces.h" +#include "hw/timer/mc146818rtc_regs.h" #ifdef TARGET_I386 #include "hw/i386/apic.h" diff --git a/include/hw/timer/mc146818rtc.h b/include/hw/timer/mc146818rtc.h index 17761cf6d9..a857dcdc69 100644 --- a/include/hw/timer/mc146818rtc.h +++ b/include/hw/timer/mc146818rtc.h @@ -5,7 +5,6 @@ #include "qemu/queue.h" #include "qemu/timer.h" #include "hw/isa/isa.h" -#include "hw/timer/mc146818rtc_regs.h" #define TYPE_MC146818_RTC "mc146818rtc" #define MC146818_RTC(obj) OBJECT_CHECK(RTCState, (obj), TYPE_MC146818_RTC) -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 07/32] MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets
From: Philippe Mathieu-Daudé The PIIX4 Southbridge is not used by the PC machine, but by the Malta board (MIPS). Add a new section to keep it covered. Suggested-by: Michael S. Tsirkin Signed-off-by: Philippe Mathieu-Daudé --- MAINTAINERS | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index fe4dc51b08..c9f625fc2e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1230,7 +1230,6 @@ F: hw/pci-host/q35.c F: hw/pci-host/pam.c F: include/hw/pci-host/q35.h F: include/hw/pci-host/pam.h -F: hw/isa/piix4.c F: hw/isa/lpc_ich9.c F: hw/i2c/smbus_ich9.c F: hw/acpi/piix4.c @@ -1716,6 +1715,12 @@ F: hw/display/edid* F: include/hw/display/edid.h F: qemu-edid.c +PIIX4 South Bridge (i82371AB) +M: Hervé Poussineau +M: Philippe Mathieu-Daudé +S: Maintained +F: hw/isa/piix4.c + Firmware configuration (fw_cfg) M: Philippe Mathieu-Daudé R: Laszlo Ersek -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 06/32] mc146818rtc: always register rtc to rtc list
From: Hervé Poussineau
We are not required anymore to use rtc_init() function.
Acked-by: Michael S. Tsirkin
Acked-by: Paolo Bonzini
Signed-off-by: Hervé Poussineau
Message-Id: <20171216090228.28505-5-hpous...@reactos.org>
[PMD: rebased, fix OBJECT() value]
Signed-off-by: Philippe Mathieu-Daudé
---
hw/timer/mc146818rtc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
index 0c04b74c2e..8f7d3a9cdf 100644
--- a/hw/timer/mc146818rtc.c
+++ b/hw/timer/mc146818rtc.c
@@ -963,17 +963,16 @@ static void rtc_realizefn(DeviceState *dev, Error **errp)
object_property_add_tm(OBJECT(s), "date", rtc_get_date, NULL);
qdev_init_gpio_out(dev, >irq, 1);
+QLIST_INSERT_HEAD(_devices, s, link);
}
ISADevice *mc146818_rtc_init(ISABus *bus, int base_year, qemu_irq
intercept_irq)
{
DeviceState *dev;
ISADevice *isadev;
-RTCState *s;
isadev = isa_create(bus, TYPE_MC146818_RTC);
dev = DEVICE(isadev);
-s = MC146818_RTC(isadev);
qdev_prop_set_int32(dev, "base_year", base_year);
qdev_init_nofail(dev);
if (intercept_irq) {
@@ -981,9 +980,8 @@ ISADevice *mc146818_rtc_init(ISABus *bus, int base_year,
qemu_irq intercept_irq)
} else {
isa_connect_gpio_out(isadev, 0, RTC_ISA_IRQ);
}
-QLIST_INSERT_HEAD(_devices, s, link);
-object_property_add_alias(qdev_get_machine(), "rtc-time", OBJECT(s),
+object_property_add_alias(qdev_get_machine(), "rtc-time", OBJECT(isadev),
"date", NULL);
return isadev;
@@ -1015,8 +1013,6 @@ static void rtc_class_initfn(ObjectClass *klass, void
*data)
dc->reset = rtc_resetdev;
dc->vmsd = _rtc;
dc->props = mc146818rtc_properties;
-/* Reason: needs to be wired up by rtc_init() */
-dc->user_creatable = false;
}
static const TypeInfo mc146818rtc_info = {
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 02/32] hw/i386/pc: Move kvm_i8259_init() declaration to sysemu/kvm.h
Move the KVM-related call to "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 1 -
include/sysemu/kvm.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 6df4f4b6fb..09e74e7764 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -158,7 +158,6 @@ typedef struct PCMachineClass {
extern DeviceState *isa_pic;
qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq);
-qemu_irq *kvm_i8259_init(ISABus *bus);
int pic_read_irq(DeviceState *d);
int pic_get_output(DeviceState *d);
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 9d143282bc..da8aa9f5a8 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -513,6 +513,7 @@ void kvm_irqchip_set_qemuirq_gsi(KVMState *s, qemu_irq irq,
int gsi);
void kvm_pc_gsi_handler(void *opaque, int n, int level);
void kvm_pc_setup_irq_routing(bool pci_enabled);
void kvm_init_irq_routing(KVMState *s);
+qemu_irq *kvm_i8259_init(ISABus *bus);
/**
* kvm_arch_irqchip_create:
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 03/32] mc146818rtc: move structure to header file
From: Hervé Poussineau
We are now able to embed a timer in another object.
Acked-by: Michael S. Tsirkin
Acked-by: Paolo Bonzini
Signed-off-by: Hervé Poussineau
Message-Id: <20171216090228.28505-4-hpous...@reactos.org>
Signed-off-by: Philippe Mathieu-Daudé
---
hw/timer/mc146818rtc.c | 30 --
include/hw/timer/mc146818rtc.h | 33 +
2 files changed, 33 insertions(+), 30 deletions(-)
diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
index 6cb378751b..e40b54e743 100644
--- a/hw/timer/mc146818rtc.c
+++ b/hw/timer/mc146818rtc.c
@@ -71,36 +71,6 @@
#define RTC_CLOCK_RATE32768
#define UIP_HOLD_LENGTH (8 * NANOSECONDS_PER_SECOND / 32768)
-#define MC146818_RTC(obj) OBJECT_CHECK(RTCState, (obj), TYPE_MC146818_RTC)
-
-typedef struct RTCState {
-ISADevice parent_obj;
-
-MemoryRegion io;
-MemoryRegion coalesced_io;
-uint8_t cmos_data[128];
-uint8_t cmos_index;
-int32_t base_year;
-uint64_t base_rtc;
-uint64_t last_update;
-int64_t offset;
-qemu_irq irq;
-int it_shift;
-/* periodic timer */
-QEMUTimer *periodic_timer;
-int64_t next_periodic_time;
-/* update-ended timer */
-QEMUTimer *update_timer;
-uint64_t next_alarm_time;
-uint16_t irq_reinject_on_ack_count;
-uint32_t irq_coalesced;
-uint32_t period;
-QEMUTimer *coalesced_timer;
-LostTickPolicy lost_tick_policy;
-Notifier suspend_notifier;
-QLIST_ENTRY(RTCState) link;
-} RTCState;
-
static void rtc_set_time(RTCState *s);
static void rtc_update_time(RTCState *s);
static void rtc_set_cmos(RTCState *s, const struct tm *tm);
diff --git a/include/hw/timer/mc146818rtc.h b/include/hw/timer/mc146818rtc.h
index fe6ed63f71..0f1c886e5b 100644
--- a/include/hw/timer/mc146818rtc.h
+++ b/include/hw/timer/mc146818rtc.h
@@ -1,10 +1,43 @@
#ifndef MC146818RTC_H
#define MC146818RTC_H
+#include "qapi/qapi-types-misc.h"
+#include "qemu/queue.h"
+#include "qemu/timer.h"
#include "hw/isa/isa.h"
#include "hw/timer/mc146818rtc_regs.h"
#define TYPE_MC146818_RTC "mc146818rtc"
+#define MC146818_RTC(obj) OBJECT_CHECK(RTCState, (obj), TYPE_MC146818_RTC)
+
+typedef struct RTCState {
+ISADevice parent_obj;
+
+MemoryRegion io;
+MemoryRegion coalesced_io;
+uint8_t cmos_data[128];
+uint8_t cmos_index;
+int32_t base_year;
+uint64_t base_rtc;
+uint64_t last_update;
+int64_t offset;
+qemu_irq irq;
+int it_shift;
+/* periodic timer */
+QEMUTimer *periodic_timer;
+int64_t next_periodic_time;
+/* update-ended timer */
+QEMUTimer *update_timer;
+uint64_t next_alarm_time;
+uint16_t irq_reinject_on_ack_count;
+uint32_t irq_coalesced;
+uint32_t period;
+QEMUTimer *coalesced_timer;
+Notifier clock_reset_notifier;
+LostTickPolicy lost_tick_policy;
+Notifier suspend_notifier;
+QLIST_ENTRY(RTCState) link;
+} RTCState;
ISADevice *mc146818_rtc_init(ISABus *bus, int base_year,
qemu_irq intercept_irq);
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 01/32] hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers
These devices implemented their load_state_old() handler 10 years
ago, previous to QEMU v0.12.
Since commit cc425b5ddf removed the pc-0.10 and pc-0.11 machines,
we can drop this code.
Note: the mips_r4k machine started to use the i8254 device just
after QEMU v0.5.0, but the MIPS machine types are not versioned,
so there is no migration compatibility issue removing this handler.
Suggested-by: Peter Maydell
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/piix4.c | 40 -
hw/intc/apic_common.c | 49 -
hw/pci-host/piix.c | 25 -
hw/timer/i8254_common.c | 40 -
4 files changed, 154 deletions(-)
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 5742c3df87..1d29d438c7 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -42,7 +42,6 @@
#include "hw/acpi/memory_hotplug.h"
#include "hw/acpi/acpi_dev_interface.h"
#include "hw/xen/xen.h"
-#include "migration/qemu-file-types.h"
#include "migration/vmstate.h"
#include "hw/core/cpu.h"
#include "trace.h"
@@ -205,43 +204,6 @@ static const VMStateDescription vmstate_pci_status = {
}
};
-static int acpi_load_old(QEMUFile *f, void *opaque, int version_id)
-{
-PIIX4PMState *s = opaque;
-int ret, i;
-uint16_t temp;
-
-ret = pci_device_load(PCI_DEVICE(s), f);
-if (ret < 0) {
-return ret;
-}
-qemu_get_be16s(f, >ar.pm1.evt.sts);
-qemu_get_be16s(f, >ar.pm1.evt.en);
-qemu_get_be16s(f, >ar.pm1.cnt.cnt);
-
-ret = vmstate_load_state(f, _apm, >apm, 1);
-if (ret) {
-return ret;
-}
-
-timer_get(f, s->ar.tmr.timer);
-qemu_get_sbe64s(f, >ar.tmr.overflow_time);
-
-qemu_get_be16s(f, (uint16_t *)s->ar.gpe.sts);
-for (i = 0; i < 3; i++) {
-qemu_get_be16s(f, );
-}
-
-qemu_get_be16s(f, (uint16_t *)s->ar.gpe.en);
-for (i = 0; i < 3; i++) {
-qemu_get_be16s(f, );
-}
-
-ret = vmstate_load_state(f, _pci_status,
->acpi_pci_hotplug.acpi_pcihp_pci_status[ACPI_PCIHP_BSEL_DEFAULT],
1);
-return ret;
-}
-
static bool vmstate_test_use_acpi_pci_hotplug(void *opaque, int version_id)
{
PIIX4PMState *s = opaque;
@@ -313,8 +275,6 @@ static const VMStateDescription vmstate_acpi = {
.name = "piix4_pm",
.version_id = 3,
.minimum_version_id = 3,
-.minimum_version_id_old = 1,
-.load_state_old = acpi_load_old,
.post_load = vmstate_acpi_post_load,
.fields = (VMStateField[]) {
VMSTATE_PCI_DEVICE(parent_obj, PIIX4PMState),
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index aafd8e0e33..375cb6abe9 100644
--- a/hw/intc/apic_common.c
+++ b/hw/intc/apic_common.c
@@ -31,7 +31,6 @@
#include "sysemu/kvm.h"
#include "hw/qdev-properties.h"
#include "hw/sysbus.h"
-#include "migration/qemu-file-types.h"
#include "migration/vmstate.h"
static int apic_irq_delivered;
@@ -262,52 +261,6 @@ static void apic_reset_common(DeviceState *dev)
apic_init_reset(dev);
}
-/* This function is only used for old state version 1 and 2 */
-static int apic_load_old(QEMUFile *f, void *opaque, int version_id)
-{
-APICCommonState *s = opaque;
-APICCommonClass *info = APIC_COMMON_GET_CLASS(s);
-int i;
-
-if (version_id > 2) {
-return -EINVAL;
-}
-
-/* XXX: what if the base changes? (registered memory regions) */
-qemu_get_be32s(f, >apicbase);
-qemu_get_8s(f, >id);
-qemu_get_8s(f, >arb_id);
-qemu_get_8s(f, >tpr);
-qemu_get_be32s(f, >spurious_vec);
-qemu_get_8s(f, >log_dest);
-qemu_get_8s(f, >dest_mode);
-for (i = 0; i < 8; i++) {
-qemu_get_be32s(f, >isr[i]);
-qemu_get_be32s(f, >tmr[i]);
-qemu_get_be32s(f, >irr[i]);
-}
-for (i = 0; i < APIC_LVT_NB; i++) {
-qemu_get_be32s(f, >lvt[i]);
-}
-qemu_get_be32s(f, >esr);
-qemu_get_be32s(f, >icr[0]);
-qemu_get_be32s(f, >icr[1]);
-qemu_get_be32s(f, >divide_conf);
-s->count_shift = qemu_get_be32(f);
-qemu_get_be32s(f, >initial_count);
-s->initial_count_load_time = qemu_get_be64(f);
-s->next_time = qemu_get_be64(f);
-
-if (version_id >= 2) {
-s->timer_expiry = qemu_get_be64(f);
-}
-
-if (info->post_load) {
-info->post_load(s);
-}
-return 0;
-}
-
static const VMStateDescription vmstate_apic_common;
static void apic_common_realize(DeviceState *dev, Error **errp)
@@ -408,8 +361,6 @@ static const VMStateDescription vmstate_apic_common = {
.name = "apic",
.version_id = 3,
.minimum_version_id = 3,
-.minimum_version_id_old = 1,
-.load_state_old = apic_load_old,
.pre_load = apic_pre_load,
.pre_save = apic_dispatch_pre_save,
.post_load = apic_dispatch_post_load,
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index 135c645535..2f4cbcbfe9 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -33,7 +33,6 @@
#include "qapi/error.h"
#include
[Xen-devel] [PATCH 00/32] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge
Hi,
This series is a rework of "piix4: cleanup and improvements" [1]
from Hervé, and my "remove i386/pc dependency: PIIX cleanup" [2].
Still trying to remove the strong X86/PC dependency 2 years later,
one step at a time.
Here we split the PIIX3 southbridge from i440FX northbridge.
The i440FX northbridge is only used by the PC machine, while the
PIIX southbridge is also used by the Malta MIPS machine.
This is also a step forward using KConfig with the Malta board.
Without this split, it was impossible to compile the Malta without
pulling various X86 pieces of code.
The overall design cleanup is not yet perfect, but enough to post
as a series.
Now that the PIIX3 code is extracted, the code duplication with the
PIIX4 chipset is obvious. Not worth improving for now because it
isn't broken.
Next step is probably:
1/ Extract i8259 from "pc.h" and sort all the places where we call
pic_*() using global variables
2/ Refactor common PIIX code from hw/i386/pc_*.c to piix*.c
Please review,
Phil.
Series available here:
branch pc_split_i440fx_piix-v1 on https://gitlab.com/philmd/qemu.git
[1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg500737.html
[2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg504081.html
Hervé Poussineau (9):
mc146818rtc: move structure to header file
mc146818rtc: always register rtc to rtc list
piix4: rename some variables in realize function
piix4: add Reset Control Register
piix4: add a i8259 interrupt controller as specified in datasheet
piix4: rename PIIX4 object to piix4-isa
piix4: convert reset function to QOM
piix4: add a i8257 dma controller as specified in datasheet
piix4: add a i8254 pit controller as specified in datasheet
Philippe Mathieu-Daudé (23):
hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers
hw/i386/pc: Move kvm_i8259_init() declaration to sysemu/kvm.h
mc146818rtc: Move RTC_ISA_IRQ definition
mc146818rtc: Include "mc146818rtc_regs.h" directly in mc146818rtc.c
MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets
Revert "irq: introduce qemu_irq_proxy()"
piix4: add a mc146818rtc controller as specified in datasheet
hw/mips/mips_malta: Create IDE hard drive array dynamically
hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create()
hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c
hw/i386/pc: Extract pc_gsi_create()
hw/i386/pc: Reduce gsi_handler scope
hw/i386/pc: Move gsi_state creation code
hw/i386/pc: Extract pc_i8259_create()
hw/i386/pc: Remove kvm_i386.h include
hw/pci-host/piix: Extract piix3_create()
hw/pci-host/piix: Move RCR_IOPORT register definition
hw/pci-host/piix: Define and use the PIIX IRQ Route Control Registers
hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.h
hw/pci-host/piix: Fix code style issues
hw/pci-host/piix: Extract PIIX3 functions to hw/isa/piix3.c
hw/pci-host: Rename incorrectly named 'piix' as 'i440fx'
hw/pci-host/i440fx: Remove the last PIIX3 traces
MAINTAINERS | 14 +-
hw/acpi/pcihp.c | 2 +-
hw/acpi/piix4.c | 42 +--
hw/core/irq.c | 14 -
hw/i386/Kconfig | 3 +-
hw/i386/acpi-build.c| 3 +-
hw/i386/pc.c| 36 ++-
hw/i386/pc_piix.c | 33 +--
hw/i386/pc_q35.c| 28 +-
hw/i386/xen/xen-hvm.c | 5 +-
hw/intc/apic_common.c | 49
hw/isa/Kconfig | 4 +
hw/isa/Makefile.objs| 1 +
hw/isa/piix3.c | 399 ++
hw/isa/piix4.c | 155 --
hw/mips/gt64xxx_pci.c | 5 +-
hw/mips/mips_malta.c| 46 +--
hw/pci-host/Kconfig | 3 +-
hw/pci-host/Makefile.objs | 2 +-
hw/pci-host/{piix.c => i440fx.c}| 424 +---
hw/timer/i8254_common.c | 40 ---
hw/timer/mc146818rtc.c | 39 +--
include/hw/acpi/piix4.h | 6 -
include/hw/i386/pc.h| 41 +--
include/hw/irq.h| 5 -
include/hw/isa/isa.h| 2 +
include/hw/pci-host/i440fx.h| 36 +++
include/hw/southbridge/piix.h | 74 +
include/hw/timer/mc146818rtc.h | 36 ++-
include/hw/timer/mc146818rtc_regs.h | 2 -
include/sysemu/kvm.h| 1 +
stubs/pci-host-piix.c | 3 +-
tests/rtc-test.c| 1 +
33 files changed, 781 insertions(+), 773 deletions(-)
create mode 100644 hw/isa/piix3.c
rename hw/pci-host/{piix.c => i440fx.c} (58%)
delete mode 100644 include/hw/acpi/piix4.h
create mode 100644 include/hw/pci-host/i440fx.h
create mode 100644 include/hw/southbridge/piix.h
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Re: [Xen-devel] [PATCH v2] xen/arm: platform: fix Raspberry Pi compatible string
On Tuesday, October 15, 2019 7:02 AM, Julien Grall wrote: >Hi, Hi! > >On 10/9/19 5:59 PM, Stewart Hildebrand wrote: >> However, even with Xen looking for bcm2838, you wouldn't be able to >> grab one of those releases and boot without running into other issues. >> You'd still need a couple of additional patches at [4]. Currently the >> only way that I'm aware of to successfully boot into dom0 and launch >> domU is to build the dom0 kernel from source with the extra patches >> applied found at [4]. > >Is there any plan to upstream those patches? Two of the patches are adding device tree nodes (xen,xen-bootargs, etc), so those are unlikely to be upstreamed. One patch is a hack/workaround to disable DMA for the SD card, also unlikely to be upstreamed. Finally, the last patch adds a check to avoid invoking xen_dma_ops recursively. This one could potentially be upstreamed, though we haven't submitted or gathered any input from the linux or raspberry pi communities yet. We are tracking the following patch sets [5] [6] [7] for upstream, and our current plan is basically to wait until they have been merged, try booting the upstream kernel, then see if it is still necessary to apply the DMA workarounds. [5] https://patchwork.kernel.org/cover/11165395/ [6] https://patchwork.kernel.org/cover/11159379/ [7] https://patchwork.kernel.org/cover/11141719/ >> "If you are using a device tree with the old compatible string >> brcm,bcm2838, you will need to upgrade your device tree to one that has >> the new brcm,bcm2711 compatible string." > >That's fine with me. OK, since it's simply a matter of adding this to the commit message, can it be added on commit? Or should I spin a v3 with the updated commit message? Finally, @Juergen, are you willing to accept this patch for 4.13? Since both upstream linux and downstream raspberry pi linux communities have decided to use the bcm2711 convention, we don't currently match this platform compatible. Meaning we can't currently boot on RPi4 without this patch. Stew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen-unstable 4.13.0-rc0 problem starting guest while trying to passthrough multiple pci devices
Hi Anthony, While testing xen-unstable 4.13.0-rc0 I ran in to the following issue: When passing through all 8 functions of a pci(e) device I can't start the guest anymore, note that the trouble only starts at 0:9:0.3, not at 0:9:0.0: libxl: error: libxl_qmp.c:1270:qmp_ev_connect: Domain 3:Failed to connect to QMP socket /var/run/xen/qmp-libxl-3: Resource temporarily unavailable libxl: error: libxl_pci.c:1702:device_pci_add_done: Domain 3:libxl__device_pci_add failed for PCI device 0:9:0.3 (rc -3) libxl: error: libxl_qmp.c:1270:qmp_ev_connect: Domain 3:Failed to connect to QMP socket /var/run/xen/qmp-libxl-3: Resource temporarily unavailable libxl: error: libxl_pci.c:1702:device_pci_add_done: Domain 3:libxl__device_pci_add failed for PCI device 0:9:0.4 (rc -3) libxl: error: libxl_qmp.c:1270:qmp_ev_connect: Domain 3:Failed to connect to QMP socket /var/run/xen/qmp-libxl-3: Resource temporarily unavailable libxl: error: libxl_pci.c:1702:device_pci_add_done: Domain 3:libxl__device_pci_add failed for PCI device 0:9:0.5 (rc -3) libxl: error: libxl_qmp.c:1270:qmp_ev_connect: Domain 3:Failed to connect to QMP socket /var/run/xen/qmp-libxl-3: Resource temporarily unavailable libxl: error: libxl_pci.c:1702:device_pci_add_done: Domain 3:libxl__device_pci_add failed for PCI device 0:9:0.6 (rc -3) libxl: error: libxl_qmp.c:1270:qmp_ev_connect: Domain 3:Failed to connect to QMP socket /var/run/xen/qmp-libxl-3: Resource temporarily unavailable libxl: error: libxl_pci.c:1702:device_pci_add_done: Domain 3:libxl__device_pci_add failed for PCI device 0:9:0.7 (rc -3) libxl: error: libxl_create.c:1609:domcreate_attach_devices: Domain 3:unable to add pci devices libxl: error: libxl_domain.c:1177:libxl__destroy_domid: Domain 3:Non-existant domain libxl: error: libxl_domain.c:1131:domain_destroy_callback: Domain 3:Unable to destroy guest libxl: error: libxl_domain.c:1058:domain_destroy_cb: Domain 3:Destruction of domain failed When only passing through the first functions 0:9:0.0 to 0:9:0.2, the guest starts. -- Sander ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: remove special dom0 case in dump_hyp_walk
Hi Stefano, On 10/15/19 4:51 PM, Stefano Stabellini wrote: On Tue, 15 Oct 2019, Julien Grall wrote: Hi Stefano, On 10/15/19 4:49 AM, Stefano Stabellini wrote: There is no need to have a special dom0 case to convert the pgtable virtual address into a physical address. The virt_to_maddr function can work both in the dom0 case and the domU case. This is more than a cleanup: when Xen is loaded at addresses lower than 2MB on arm32 phys_offset might not hold the right value and be unable to perform a virt to phys conversion properly. Reducing the unnecessary usage of phys_offset is a good idea. Aside what Juergen said, this paragraph raises the question why phys_offset is actually not modified (or completely dropped)? After all, if the value holds is wrong then other users may get wrong value as well... Should I add something like "this is not a fix, but reducing unnecessary[...]" ? dump_hyp_walk() is only used in two places: - when hardware translation failed - Hypervisor data abort In both case we will panic afterwards. So hitting the BUG_ON() is just only a matter of losing page-table information. So I see limited reason to see this patch alone in Xen 4.13. We should either completely fix phys_offset or do nothing. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: remove special dom0 case in dump_hyp_walk
On Tue, 15 Oct 2019, Julien Grall wrote: > Hi Stefano, > > On 10/15/19 4:49 AM, Stefano Stabellini wrote: > > There is no need to have a special dom0 case to convert the pgtable > > virtual address into a physical address. The virt_to_maddr function can > > work both in the dom0 case and the domU case. > > > > This is more than a cleanup: when Xen is loaded at addresses lower than > > 2MB on arm32 phys_offset might not hold the right value and be unable to > > perform a virt to phys conversion properly. Reducing the unnecessary > > usage of phys_offset is a good idea. > > Aside what Juergen said, this paragraph raises the question why phys_offset is > actually not modified (or completely dropped)? After all, if the value holds > is wrong then other users may get wrong value as well... Should I add something like "this is not a fix, but reducing unnecessary[...]" ? ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: remove special dom0 case in dump_hyp_walk
On Tue, 15 Oct 2019, Jürgen Groß wrote:
> On 15.10.19 05:49, Stefano Stabellini wrote:
> > There is no need to have a special dom0 case to convert the pgtable
> > virtual address into a physical address. The virt_to_maddr function can
> > work both in the dom0 case and the domU case.
> >
> > This is more than a cleanup: when Xen is loaded at addresses lower than
> > 2MB on arm32 phys_offset might not hold the right value and be unable to
> > perform a virt to phys conversion properly. Reducing the unnecessary
> > usage of phys_offset is a good idea.
> >
> > Link: https://marc.info/?l=xen-devel=157081398022401
> > Signed-off-by: Stefano Stabellini
> >
> > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > index a6637ce347..b7883cfbab 100644
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -284,10 +284,7 @@ void dump_hyp_walk(vaddr_t addr)
> > "on CPU%d via TTBR 0x%016"PRIx64"\n",
> > addr, smp_processor_id(), ttbr);
> > -if ( smp_processor_id() == 0 )
> > -BUG_ON( (lpae_t *)(unsigned long)(ttbr - phys_offset) != pgtable );
> > -else
> > -BUG_ON( virt_to_maddr(pgtable) != ttbr );
> > +BUG_ON( virt_to_maddr(pgtable) != ttbr );
> > dump_pt_walk(ttbr, addr, HYP_PT_ROOT_LEVEL, 1);
> > }
>
> I can't make a connection between commit message ("special dom0 case")
> and the code modification. The special case removed is about cpu 0, not
> dom0.
That's what happen when I write a commit message late in the night.
Sorry about that. I'll resend it.___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 4/4] iommu: translate IO-APIC pins when enabling interrupt remapping
On Intel hardware there's currently no translation of already enabled
IO-APIC pins when interrupt remapping is enabled on the IOMMU, hence
introduce a logic similar to the one used in x2apic_bsp_setup in order
to save and mask all IO-APIC pins, and then translate and restore them
after interrupt remapping has been enabled.
With this change the AMD specific logic to deal with enabled pins
(amd_iommu_setup_ioapic_remapping) can be removed, thus unifying the
handling of IO-APIC when enabling interrupt remapping regardless of
the IOMMU vendor.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Juergen Gross
---
xen/drivers/passthrough/amd/iommu_init.c | 11 ++-
xen/drivers/passthrough/amd/iommu_intr.c | 90 +--
xen/drivers/passthrough/x86/iommu.c | 34 ++-
xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 1 +
4 files changed, 40 insertions(+), 96 deletions(-)
diff --git a/xen/drivers/passthrough/amd/iommu_init.c
b/xen/drivers/passthrough/amd/iommu_init.c
index 6f53c7ec08..3c244619b9 100644
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1435,12 +1436,6 @@ int __init amd_iommu_init(bool xt)
if ( rc )
goto error_out;
-/* initialize io-apic interrupt remapping entries */
-if ( iommu_intremap )
-rc = amd_iommu_setup_ioapic_remapping();
-if ( rc )
-goto error_out;
-
/* Allocate and initialize device table(s). */
pci_init = !xt;
rc = iterate_ivrs_mappings(amd_iommu_setup_device_table);
@@ -1469,6 +1464,10 @@ int __init amd_iommu_init(bool xt)
goto error_out;
}
+if ( iommu_intremap )
+register_keyhandler('V', _iommu_dump_intremap_tables,
+"dump IOMMU intremap tables", 0);
+
return 0;
error_out:
diff --git a/xen/drivers/passthrough/amd/iommu_intr.c
b/xen/drivers/passthrough/amd/iommu_intr.c
index 02dd3737c7..22e8c2391c 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -21,7 +21,6 @@
#include
#include
#include
-#include
#include
union irte32 {
@@ -79,8 +78,6 @@ unsigned long *shared_intremap_inuse;
static DEFINE_SPINLOCK(shared_intremap_lock);
unsigned int nr_ioapic_sbdf;
-static void dump_intremap_tables(unsigned char key);
-
#define intremap_page_order(irt) PFN_ORDER(virt_to_page(irt))
unsigned int amd_iommu_intremap_table_order(
@@ -354,91 +351,6 @@ static int update_intremap_entry_from_ioapic(
return 0;
}
-int __init amd_iommu_setup_ioapic_remapping(void)
-{
-struct IO_APIC_route_entry rte;
-unsigned long flags;
-union irte_ptr entry;
-int apic, pin;
-u8 delivery_mode, dest, vector, dest_mode;
-u16 seg, bdf, req_id;
-struct amd_iommu *iommu;
-spinlock_t *lock;
-unsigned int offset;
-
-/* Read ioapic entries and update interrupt remapping table accordingly */
-for ( apic = 0; apic < nr_ioapics; apic++ )
-{
-for ( pin = 0; pin < nr_ioapic_entries[apic]; pin++ )
-{
-unsigned int idx;
-
-rte = __ioapic_read_entry(apic, pin, 1);
-if ( rte.mask == 1 )
-continue;
-
-/* get device id of ioapic devices */
-idx = ioapic_id_to_index(IO_APIC_ID(apic));
-if ( idx == MAX_IO_APICS )
-return -EINVAL;
-
-bdf = ioapic_sbdf[idx].bdf;
-seg = ioapic_sbdf[idx].seg;
-iommu = find_iommu_for_device(seg, bdf);
-if ( !iommu )
-{
-AMD_IOMMU_DEBUG("Fail to find iommu for ioapic "
-"device id = %04x:%04x\n", seg, bdf);
-continue;
-}
-
-req_id = get_intremap_requestor_id(iommu->seg, bdf);
-lock = get_intremap_lock(iommu->seg, req_id);
-
-delivery_mode = rte.delivery_mode;
-vector = rte.vector;
-dest_mode = rte.dest_mode;
-dest = rte.dest.logical.logical_dest;
-
-if ( iommu->ctrl.xt_en )
-{
-/*
- * In x2APIC mode we have no way of discovering the high 24
- * bits of the destination of an already enabled interrupt.
- * We come here earlier than for xAPIC mode, so no interrupts
- * should have been set up before.
- */
-AMD_IOMMU_DEBUG("Unmasked IO-APIC#%u entry %u in x2APIC
mode\n",
-IO_APIC_ID(apic), pin);
-}
-
-spin_lock_irqsave(lock, flags);
-offset = alloc_intremap_entry(iommu, req_id, 1);
-BUG_ON(offset >= INTREMAP_MAX_ENTRIES);
-entry = get_intremap_entry(iommu, req_id, offset);
-update_intremap_entry(iommu,
[Xen-devel] [PATCH v3 3/4] x2APIC: translate IO-APIC entries when enabling the IOMMU
When interrupt remapping is enabled as part of enabling x2APIC the
IO-APIC entries also need to be translated to the new format and added
to the interrupt remapping table.
This prevents IOMMU interrupt remapping faults when booting on
hardware that has unmasked IO-APIC pins.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Cc: Juergen Gross
---
Changes since v2:
- Introduce intremap_enabled.
Changes since v1:
- Remove the unneeded iommu_enabled local variable.
---
xen/arch/x86/apic.c | 11 ++-
xen/arch/x86/io_apic.c| 5 +++--
xen/include/asm-x86/io_apic.h | 3 ++-
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 0607eb92a8..a5f7b05d5a 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -860,6 +860,7 @@ void __init x2apic_bsp_setup(void)
{
struct IO_APIC_route_entry **ioapic_entries = NULL;
const char *orig_name;
+bool intremap_enabled;
if ( !cpu_has_x2apic )
return;
@@ -902,11 +903,13 @@ void __init x2apic_bsp_setup(void)
switch ( iommu_enable_x2apic() )
{
case 0:
+intremap_enabled = true;
break;
case -ENXIO: /* ACPI_DMAR_X2APIC_OPT_OUT set */
if ( !x2apic_enabled )
{
printk("Not enabling x2APIC (upon firmware request)\n");
+intremap_enabled = false;
goto restore_out;
}
/* fall through */
@@ -917,6 +920,7 @@ void __init x2apic_bsp_setup(void)
printk(XENLOG_ERR
"Failed to enable Interrupt Remapping: Will not enable
x2APIC.\n");
+intremap_enabled = false;
goto restore_out;
}
@@ -934,7 +938,12 @@ void __init x2apic_bsp_setup(void)
printk("Switched to APIC driver %s\n", genapic.name);
restore_out:
-restore_IO_APIC_setup(ioapic_entries);
+/*
+ * NB: do not use raw mode when restoring entries if the iommu has been
+ * enabled during the process, because the entries need to be translated
+ * and added to the remapping table in that case.
+ */
+restore_IO_APIC_setup(ioapic_entries, !intremap_enabled);
unmask_8259A();
out:
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index 5d25862bd8..37eabc16c9 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -379,7 +379,8 @@ void mask_IO_APIC_setup(struct IO_APIC_route_entry
**ioapic_entries)
/*
* Restore IO APIC entries which was saved in ioapic_entries.
*/
-int restore_IO_APIC_setup(struct IO_APIC_route_entry **ioapic_entries)
+int restore_IO_APIC_setup(struct IO_APIC_route_entry **ioapic_entries,
+ bool raw)
{
int apic, pin;
@@ -394,7 +395,7 @@ int restore_IO_APIC_setup(struct IO_APIC_route_entry
**ioapic_entries)
return -ENOMEM;
for (pin = 0; pin < nr_ioapic_entries[apic]; pin++)
- ioapic_write_entry(apic, pin, 1, ioapic_entries[apic][pin]);
+ ioapic_write_entry(apic, pin, raw, ioapic_entries[apic][pin]);
}
return 0;
diff --git a/xen/include/asm-x86/io_apic.h b/xen/include/asm-x86/io_apic.h
index 0b041f0565..998905186b 100644
--- a/xen/include/asm-x86/io_apic.h
+++ b/xen/include/asm-x86/io_apic.h
@@ -197,7 +197,8 @@ extern struct IO_APIC_route_entry
**alloc_ioapic_entries(void);
extern void free_ioapic_entries(struct IO_APIC_route_entry **ioapic_entries);
extern int save_IO_APIC_setup(struct IO_APIC_route_entry **ioapic_entries);
extern void mask_IO_APIC_setup(struct IO_APIC_route_entry **ioapic_entries);
-extern int restore_IO_APIC_setup(struct IO_APIC_route_entry **ioapic_entries);
+extern int restore_IO_APIC_setup(struct IO_APIC_route_entry **ioapic_entries,
+ bool raw);
unsigned highest_gsi(void);
--
2.23.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 2/4] x2APIC: simplify resume
There's no need to save and restore the IO-APIC entries, the entries
prior to suspension have already been saved by ioapic_suspend, and
will be restored by ioapic_resume. Note that at the point where
resume_x2apic gets called the IO-APIC has not yet resumed, and hence
all entries should be masked.
Note this shouldn't introduce any functional change.
Suggested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
I'm Ccing Marek since I think he usually tests suspend/resume. Could
you give this patch a try?
---
Cc: Marek Marczykowski-Górecki
Cc: Juergen Gross
---
Changes since v2:
- New in this version.
---
xen/arch/x86/apic.c | 27 ---
1 file changed, 27 deletions(-)
diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 6cdb50cf41..0607eb92a8 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -492,35 +492,8 @@ static void __enable_x2apic(void)
static void resume_x2apic(void)
{
-struct IO_APIC_route_entry **ioapic_entries = NULL;
-
-ASSERT(x2apic_enabled);
-
-ioapic_entries = alloc_ioapic_entries();
-if ( !ioapic_entries )
-{
-printk("Allocate ioapic_entries failed\n");
-goto out;
-}
-
-if ( save_IO_APIC_setup(ioapic_entries) )
-{
-printk("Saving IO-APIC state failed\n");
-goto out;
-}
-
-mask_8259A();
-mask_IO_APIC_setup(ioapic_entries);
-
iommu_enable_x2apic();
__enable_x2apic();
-
-restore_IO_APIC_setup(ioapic_entries);
-unmask_8259A();
-
-out:
-if ( ioapic_entries )
-free_ioapic_entries(ioapic_entries);
}
void setup_local_APIC(void)
--
2.23.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 1/4] iommu/amd: support all delivery modes with x2APIC
Current AMD IOMMU code will attempt to create remapping entries for
all IO-APIC pins, regardless of the delivery mode. AMD IOMMU
implementation doesn't support remapping entries for IO-APIC pins with
delivery mode set to SMI, MNI, INIT or ExtINT, instead those entries
are not translated provided the right bits are set in the device table
entry.
This change checks whether the device table entry has the correct bits
set in order to delivery the requested interrupt or a warning message
is printed. It also translates the 32bit destination field into a
physical or logical IO-APIC entry format. Note that if the 32bit
destination cannot fit into the legacy format a message is printed and
the entry is masked.
Signed-off-by: Roger Pau Monné
---
My AMD hardware doesn't have any of such entries, hence I've only been
able to compile test this change and assert it doesn't affect the
functionality of other interrupt delivery modes.
---
xen/drivers/passthrough/amd/iommu_intr.c | 81
1 file changed, 81 insertions(+)
diff --git a/xen/drivers/passthrough/amd/iommu_intr.c
b/xen/drivers/passthrough/amd/iommu_intr.c
index fb71073c84..02dd3737c7 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -439,6 +439,80 @@ int __init amd_iommu_setup_ioapic_remapping(void)
return 0;
}
+void setup_forced_ioapic_rte(unsigned int apic, unsigned int pin,
+ struct amd_iommu *iommu,
+ struct IO_APIC_route_entry *rte)
+{
+unsigned int idx = ioapic_id_to_index(IO_APIC_ID(apic));
+struct amd_iommu_dte *table = iommu->dev_table.buffer;
+unsigned int req_id, dest, offset;
+union irte_ptr entry;
+
+ASSERT(x2apic_enabled);
+
+if ( idx == MAX_IO_APICS )
+{
+rte->mask = true;
+return;
+}
+
+req_id = get_intremap_requestor_id(ioapic_sbdf[idx].seg,
+ ioapic_sbdf[idx].bdf);
+
+switch ( rte->delivery_mode )
+{
+case dest_SMI:
+break;
+
+#define DEL_CHECK(type, dte_field) \
+case dest_ ## type: \
+if ( !table[req_id].dte_field ) \
+printk(XENLOG_WARNING \
+ STR(type) " on IO-APIC %u pin %u will be aborted\n", \
+ apic, pin); \
+break;
+
+DEL_CHECK(NMI, nmi_pass);
+DEL_CHECK(INIT, init_pass);
+DEL_CHECK(ExtINT, ext_int_pass);
+#undef DEL_CHECK
+
+default:
+ASSERT_UNREACHABLE();
+return;
+}
+
+offset = ioapic_sbdf[idx].pin_2_idx[pin];
+if ( offset >= INTREMAP_MAX_ENTRIES )
+{
+rte->mask = true;
+return;
+}
+
+entry = get_intremap_entry(iommu, req_id, offset);
+dest = get_full_dest(entry.ptr128);
+
+#define SET_DEST(name, dest_mask) {
\
+if ( dest & ~(dest_mask) )
\
+{
\
+printk(XENLOG_WARNING
\
+ "IO-APIC %u pin %u " STR(name) " destination (%x) > %x\n",
\
+ apic, pin, dest, dest_mask);
\
+rte->mask = true;
\
+return;
\
+}
\
+rte->dest.name.name ## _dest = dest;
\
+}
+
+if ( rte->dest_mode )
+SET_DEST(physical, 0xf)
+else
+SET_DEST(logical, 0xff)
+#undef SET_DEST
+
+return;
+}
+
void amd_iommu_ioapic_update_ire(
unsigned int apic, unsigned int reg, unsigned int value)
{
@@ -482,6 +556,13 @@ void amd_iommu_ioapic_update_ire(
*((u32 *)_rte) = value;
/* read upper 32 bits from io-apic rte */
*(((u32 *)_rte) + 1) = __io_apic_read(apic, reg + 1);
+
+if ( new_rte.delivery_mode > 1 && x2apic_enabled )
+{
+setup_forced_ioapic_rte(apic, pin, iommu, _rte);
+__ioapic_write_entry(apic, pin, true, new_rte);
+return;
+}
}
else
{
--
2.23.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 0/4] iommu: fixes for interrupt remapping enabling
Hello, The following series contain fixes for issues found when enabling interrupt remapping and the IO-APIC already has unmasked pins. While I'm not aware of any system malfunctioning (apart from reporting IOMMU interrupt remapping faults) I think it would be nice to have those in 4.13. The series can also be found at: git://xenbits.xen.org/people/royger/xen.git iommu_intr_v3 Thanks, Roger. Roger Pau Monne (4): iommu/amd: support all delivery modes with x2APIC x2APIC: simplify resume x2APIC: translate IO-APIC entries when enabling the IOMMU iommu: translate IO-APIC pins when enabling interrupt remapping xen/arch/x86/apic.c | 38 ++--- xen/arch/x86/io_apic.c| 5 +- xen/drivers/passthrough/amd/iommu_init.c | 11 +- xen/drivers/passthrough/amd/iommu_intr.c | 141 +- xen/drivers/passthrough/x86/iommu.c | 34 - xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 1 + xen/include/asm-x86/io_apic.h | 3 +- 7 files changed, 121 insertions(+), 112 deletions(-) -- 2.23.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 2/2] libxl: add removing XS backend path for PV devices on domain destroy
On Fri, Oct 11, 2019 at 04:55:32PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("Re: [PATCH v1 2/2] libxl: add removing XS backend
> path for PV devices on domain destroy"):
> > When this code was added (devd) those where the only backends handled
> > by libxl. VDISPL, VSND, VINPUT didn't exist at that point, so I think
> > the issue is that when support for those was added, it wasn't properly
> > wired into devd.
> >
> > > I think:
> > >
> > > > switch(ddev->dev->backend_kind) {
> > > > +case LIBXL__DEVICE_KIND_VDISPL:
> > > > +case LIBXL__DEVICE_KIND_VSND:
> > > > +case LIBXL__DEVICE_KIND_VINPUT:
> > > > case LIBXL__DEVICE_KIND_VBD:
> > > > case LIBXL__DEVICE_KIND_VIF:
> > >
> > > If we do want this to handle *all* kinds of device, maybe it should
> > > have a fallback that aborts, or something ? (I don't think it is
> > > easy to make it a compile error to forget to add an entry here but if
> > > we could do that it would probably be best.)
> >
> > Maybe we could have some generic handling for everything != qdisk?
>
> So make that the "default:" ? That would be fine by me.
If possible yes, that would be my preference, and would prevent having
to add new device types to this switch unless special handling is
required.
>
> > IIRC qdisk needs special handling so that devd can launch and destroy
> > a QEMU instance when required, but other backends that run in the
> > kernel don't need such handling and could maybe share the same generic
> > code path.
>
> Right.
>
> > > All of that assuming that the basic idea is right, which I would like
> > > Roger's opinion about.
> >
> > Looking at the patch itself, you also seem to be doing some changes
> > related to num_vbds and num_vifs, but those are not mentioned in the
> > commit message, is that a stray change?
>
> No, I don't think so. Those variables just tell us when the thing is
> torn down but Oleksandr's code is able to use the devices slist itself
> for that. Please do check to see if you agree.
Yes, that's fine. I don't think those changes are wrong, I just think
that at least they should be mentioned in the commit message. Ie:
"while there remove the num_vifs and num_vbds since they are not
needed and the same can be achieved by checking that the device list
is empty." or some such.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 142751: regressions - FAIL
flight 142751 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/142751/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 140282 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 140282 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 140282 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 140282 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 140282 test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 140282 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 140282 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140282 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 140282 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check
[Xen-devel] [linux-linus bisection] complete test-amd64-i386-qemut-rhel6hvm-amd
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-qemut-rhel6hvm-amd testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: 2581efa9a47d3c9c349c6d6a2756a16bf69d3f4f Bug not present: 46713c3d2f8da5e3d8ddd2249bcb1d9974fb5d28 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/142775/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-qemut-rhel6hvm-amd.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-qemut-rhel6hvm-amd.xen-boot --summary-out=tmp/142775.bisection-summary --basis-template=133580 --blessings=real,real-bisect linux-linus test-amd64-i386-qemut-rhel6hvm-amd xen-boot Searching for failure / basis pass: 142709 fail [host=pinot1] / 138849 [host=rimava1] 138813 ok. Failure / basis pass flights: 142709 / 138813 (tree with no url: minios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest 2581efa9a47d3c9c349c6d6a2756a16bf69d3f4f c530a75c1e6a472b0eb9558310b518f0dfcd8860 410c4d00d9f7e369d1ce183e9e8de98cb59c4d20 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 43f5df79dad6738d52ea79d072de2b56eb96a91f fef8d99fbce1a5e7ddfd22b0f33940b8d6193ec8 Basis pass 46713c3d2f8da5e3d8ddd2249bcb1d9974fb5d28 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d031fc07eb83c9d13bff3ebac25da458d5a47917 d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 93ef224d63f9f04a0897d64981c619eb4816c0d3 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#46713c3d2f8da5e3d8ddd2249bcb1d9974fb5d28-2581efa9a47d3c9c349c6d6a2756a16bf69d3f4f git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#d031fc07eb83c9d13bff3ebac25da458d5a47917-410c4d00d9f7e369d1ce183e9e8de98cb59c4d20 git://xenbits.xen.org/qemu-xen-traditional.\ git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/osstest/seabios.git#30f1e41f04fb4c715d27f987f003cfc31c9ff4f3-43f5df79dad6738d52ea79d072de2b56eb96a91f git://xenbits.xen.org/xen.git#93ef224d63f9f04a0897d64981c619eb4816c0d3-fef8d99fbce1a5e7ddfd22b0f33940b8d6193ec8 adhoc-revtuple-generator: tree discontiguous: linux-2.6 adhoc-revtuple-generator: tree discontiguous: qemu-xen Loaded 3003 nodes in revision graph Searching for test results: 138845 pass irrelevant 138843 pass irrelevant 138780 pass irrelevant 138812 pass irrelevant 138813 pass 46713c3d2f8da5e3d8ddd2249bcb1d9974fb5d28 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d031fc07eb83c9d13bff3ebac25da458d5a47917 d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 93ef224d63f9f04a0897d64981c619eb4816c0d3 138847 pass irrelevant 138849 [host=rimava1] 138878 fail irrelevant 138902 fail irrelevant 138962 fail irrelevant 139003 fail irrelevant 139068 fail irrelevant 139134 fail irrelevant 139237 fail irrelevant 139223 fail irrelevant 139257 fail irrelevant 139324 fail irrelevant 139306 fail irrelevant 139286 fail irrelevant 139338 fail irrelevant 139361 fail irrelevant 139383 fail irrelevant 139408 fail irrelevant 139478 fail irrelevant 139532 fail irrelevant 139584 fail irrelevant 139555 fail irrelevant 139687 fail irrelevant 139616 fail irrelevant 139669 fail irrelevant 139711 fail irrelevant 139735 fail irrelevant 139792 fail irrelevant 139832 fail irrelevant 139961 pass irrelevant 139939 fail irrelevant 139942 fail irrelevant 139928 pass 46713c3d2f8da5e3d8ddd2249bcb1d9974fb5d28
[Xen-devel] [xen-unstable test] 142750: tolerable FAIL - PUSHED
flight 142750 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/142750/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 142683 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 142722 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142722 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142722 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142722 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 142722 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142722 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 142722 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142722 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142722 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 142722 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass version targeted for testing: xen 518c935fac4d30b3ec35d4b6add82b17b7d7aca3 baseline version: xen fef8d99fbce1a5e7ddfd22b0f33940b8d6193ec8 Last test of basis 142722 2019-10-14 01:52:52 Z
Re: [Xen-devel] [PATCH v3 0/2] Optionally call EFI SetVirtualAddressMap()
On Sat, Oct 12, 2019 at 6:11 PM Marek Marczykowski-Górecki wrote: > > Workaround buggy UEFI accessing boot services memory after ExitBootServices(). > Patches discussed here: > https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00701.html > > In addition to the tests below, I've tested kexec on xen.efi with this option > enabled and it (still) works. > > Test results on few laptops: > > Thinkpad x230, firmware version 2.77: > - without the patch: crashes on RS call (mapbs helps) > - with patch: works > - same with xen.efi and MB2 > > Librem 14 v1, firmware version (AMI) ARUD026 (06/18/2015): > - without the patch: works > - with the patch: works > - same with xen.efi and MB2 > > Dell Latitude E6420, firmware version A21: > this machine requires efi=attr=uc workaround > - without the patch: dom0 hangs before sending any message to the console > (even with earlyprintk=xen etc) > - with the patch: crashes before dom0 prints anything: mm.c:896:d0v0 > non-privileged attempt to map MMIO space 2c2c2c2c2c > - same with xen.efi and MB2 > > Thinkpad W540: > - without the patch: crashes on RS call (only efi=no-rs helps) > - with patch: works > - tested only with MB2 > > Thinkpad X1 Carbon gen5, firmware version 1.22 (2017-07-04): > - without the patch: works > - with patch: works > - tested only xen.efi > > Thinkpad P52, firmware version 1.25 (2018-04-15): > - without the patch (MB2): hangs on RS call (mapbs helps) > - without the patch (xen.efi): works(?!) > - with the patch: works > - tested with xen.efi and MB2 > > Changes in v2: > - fix boot with xen.efi (efi_memmap at this point still needs to be accessed >via physical address). TBH, I don't understand why previous version worked >with MB2 - is directmap mapped at this point? v1 failed to boot for me. For v3: Dell Latitude 5580, firmware 1.16.0 - without the patch: works - with patch: works - tested only xen.efi Tested-by: Jason Andryuk ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure
Hi Rich, > On 15 Oct 2019, at 02:58, Rich Persaud wrote: > >> On Oct 11, 2019, at 07:11, Lars Kurth wrote: >> >> On 11/10/2019, 02:24, "Stefano Stabellini" wrote: >> >>>On Thu, 10 Oct 2019, Lars Kurth wrote: >>> >>> @Stefano: as you and I believe Brian will be spending time on improving the >>> ABI docs, I think we need to build some agreement here on what/how >>> to do it. I was assuming that generally the consensus was to have >>> docs close to the code in source, but this does not seem to be the case. >>> >>> But if we do have stuff separately, ideally we would have a tool that helps >>> point people editing headers to also look at the relevant docs. Otherwise >>> it will >>> be hard to keep them in sync. >> >>In general, it is a good idea to keep the docs close to the code to make >>it easier to keep them up to date. But there is no one-size-fits-all >>here. For public ABI descriptions, I agree with Andrew that ideally they >>should not be defined as C header files. >> >>But it is not an issue: any work that we do here won't be wasted. For >>instance, we could start by adding more comments to the current header >>files. Then, as a second step, take all the comments and turn them into >>a proper ABI description document without any C function declarations. >>It is easy to move English text around, as long as the license allows it >>-- that is the only potential blocker I can see. >> >> This is likely to be problematic. First of all, we are talking about >> BSD-3-Clause >> or BSD-2-Clause code (the latter is more dominant in headers I believe) in >> all known cases. >> >> The main properties of the BSD are >> 1: Can be pretty much used anywhere for any purpose >> 2: Can be modified for any purpose >> 3: But the original license header must be retained in derivates > > This is equivalent to attribution of the copyright owner of the originally > created file. > >> Does *not* have requirements around attribution as CC-BY-4: however, >> as we store everything in git attribution is handled by us by default > > See above, the license header attributes copyright, since BSD was created for > "software" and people who work on "software" would typically be looking at > source code, hence the primary attribution takes place there, with secondary > attribution in EULAs, "About" panels, etc. > >> CC-BY-4 also has properties 1-3 >> In addition: it does require that >> 4: Derived works are giving appropriate credit to authors >>We could clarify in a COPYING how we prefer to do this >>4.1: We could say that "referring to the Xen Project community" >>is sufficient to comply with the attribution clause > > One motivation for CC-BY (with attribution) is to create an incentive > (credit) for the creation of documentation, which is not commonly a favorite > pastime of developers. Credit typically goes at least to the original > author of a section of documentation, with varying ways of crediting > subsequent contributors. The documentation can be structured to make > crediting easier. The mechanism for crediting can be designed to encourage > specific outcomes, along our projected doc lifecycle for safety > certification, contributors, evaluators and commercial investors. My point really was is that due to storing the files in git, we essentially do NOT today do this. So we would need to take extra action: e.g. manually or through tooling >>4.2: We could require individual authors to be credited: in that >>case we probably ought to lead by example and list the authors >>in a credit/license section and extract the information from >>git logs when we generate it (at some point in the future) >> 5: You give an indication whether you made changes ... in practice >> this means you have to state significant changes made to the works > > This is also helpful for provenance of changes, which is relevant in > safety-oriented documentation. It can be used to clearly delineate > CC-licensed content (which may be reused by many companies) from "All Rights > Reserved" commercial content that may be added for a specific commercial > audience or purpose. I agree I think the outcome of this analysis is really that the only significant difference between BSD and CC-BY in this context is the "All Rights Reserved" portion > There is a difference between "software" which "runs on machines" and > "documentation" which "runs on humans". Combined software (e.g. BSD code > from two origins) is executed identically, despite origin. Humans make value > judgements based on the author/origin of content, hence the focus on > attribution. Yes, there is a provenance graph in git (software/data), but > that's not typically visible to human readers, except as a generated report, > i.e. documentation. Yes true. But also true for CC-BY-4 sources stored in git unless extra action is taken
Re: [Xen-devel] [PATCH] arm/gic: Make sense of assertions
Hello, On 15.10.19 14:08, Julien Grall wrote: To be honest, those ASSERTIONs are pointless. I'd prefer to drop them. -- Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic
On Mon, Oct 14, 2019 at 05:59:26PM +0100, Anthony PERARD wrote:
> On Mon, Oct 14, 2019 at 05:09:24PM +0100, Ian Jackson wrote:
> > Paul Durrant writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
> > Overhaul passthrough setting logic"):
> > > On Fri, 11 Oct 2019 at 17:34, Ian Jackson wrote:
> > > >
> > > > Jürgen Groß writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9]
> > > > libxl/xl: Overhaul passthrough setting logic"):
> > > > > On 11.10.19 15:31, Ian Jackson wrote:
> > > > > > I do not have a strong opinion about this. I would be happy with
> > > > > > "auto" (or "default" maybe).
> > > > >
> > > > > "unspecified"?
> > > >
> > > > That is IMO the best suggestion so far so I will go with that in my
> > > > v3.
> > >
> > > Seems odd to specify a parameter with a value of 'unspecified' ;-)
> >
> > I have tried to infer +1/-1/0 numbers from the mail thread. I have
> > also looked at libxl_types.idl to see how many times we are using
> > what name to represent roughly this concept:
> >
> > Bikeshed colour Paul Juergen George Ian Anthony Wei #already
> >
> > unknown ? ? -1+2? ?17
> > default ? ? ? 0? ? 2
> > auto -1 ? +1 0? ? 1
> > unspecified -1 +1? 0? ? 0
> >
> >
> > libxl maintainers
>
> Maybe "unknown" is more used in the API, but when I look at the manpage
> "unknown" value as never been used before. On the other hand "default"
> as been used twice in the man page. (and one "defaults" and two other
> "default" that I'm not sure if they can be in the config file.)
>
> So I would say +2 for default and +1 for unknown.
Either is fine as long as it is clearly documented. If you feel strongly
about "default", so be it. :-)
Wei.
>
> --
> Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] arm/gic: Make sense of assertions
Hi,
On 10/15/19 11:01 AM, Andrii Anisov wrote:
From: Andrii Anisov
ARM Compiler complains about assertion conditions being always true,
because sgi is of enum type what has all its values under 16.
In order to preserve those asserts, specify the available SGI number
right in the enum and use it for the assertions. This also eliminates
nasty hardcoded values.
To be honest, those ASSERTIONs are pointless. If we are really worry of
enum gic_sgi to have more than 16 values, then it would be best to use a
BUILD_BUG_ON(). So you can get a build failure if that's every happening.
Something like:
static void __init __maybe_unused build_assertions(void)
{
BUILD_BUG_ON(GIC_SGI_MAX > NR_GIC_SGI);
}
enum
{
/* Use for sanity check on the size of the enum */
GIC_MAX_SGI;
}
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/arm: platform: fix Raspberry Pi compatible string
Hi, On 10/9/19 5:59 PM, Stewart Hildebrand wrote: On Wednesday, October 9, 2019 11:30 AM, Julien Grall wrote: On 04/10/2019 01:47, Stewart Hildebrand wrote: Both upstream [1] and downstream [2] Linux kernels use "brcm,bcm2711" as the compatible string for Raspberry Pi 4. Add this string to our platform compatible list. Did the RPI foundation released any kernel with the old binding? Sure, I see the following tags in their linux tree since initial RPi4 support until the binding was updated: raspberrypi-kernel_1.20190709-1 raspberrypi-kernel_1.20190718-1 raspberrypi-kernel_1.20190819-1 raspberrypi-kernel_1.20190925-1 These correspond with their binary releases at [3], except the binary releases also have an earlier 1.20190620+1 tag with RPi4 support. However, even with Xen looking for bcm2838, you wouldn't be able to grab one of those releases and boot without running into other issues. You'd still need a couple of additional patches at [4]. Currently the only way that I'm aware of to successfully boot into dom0 and launch domU is to build the dom0 kernel from source with the extra patches applied found at [4]. Is there any plan to upstream those patches? If so, I am ok if we don't support the compatible in Xen (we don't have a release with it yet!), but it would be worth mentioning in the commit message that this is going to break for some users (TBD) so they need to upgrade. See below for suggestion. @Juergen: I would like to consider this patch for Xen 4.13. This is limited to RPI4 and would avoid us to ship it with a compatible that is going to disappear. The brcm,bcm2838 convention is abandoned. Remove it. Rename the variables within the file to a rpi4_* prefix since the file is meant to cover the Raspberry Pi 4 platform. "If you are using a device tree with the old compatible string brcm,bcm2838, you will need to upgrade your device tree to one that has the new brcm,bcm2711 compatible string." That's fine with me. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: remove special dom0 case in dump_hyp_walk
Hi Stefano, On 10/15/19 4:49 AM, Stefano Stabellini wrote: There is no need to have a special dom0 case to convert the pgtable virtual address into a physical address. The virt_to_maddr function can work both in the dom0 case and the domU case. This is more than a cleanup: when Xen is loaded at addresses lower than 2MB on arm32 phys_offset might not hold the right value and be unable to perform a virt to phys conversion properly. Reducing the unnecessary usage of phys_offset is a good idea. Aside what Juergen said, this paragraph raises the question why phys_offset is actually not modified (or completely dropped)? After all, if the value holds is wrong then other users may get wrong value as well... Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v3 05/10] libxl: Move shadow_memkb and iommu_memkb defaulting into libxl
On Mon, Oct 14, 2019 at 06:00:23PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v3 05/10] libxl:
> Move shadow_memkb and iommu_memkb defaulting into libxl"):
> > So maybe libxl__domain_build_info_setdefault() should also set a value
> > to iommu_memkb as it does for shadow_memkb? At least, set iommu_memkb=0
> > if still the default.
>
> I think, this.
>
> Ian.
>
> From 379d8eb69f713cccf7eacb4c2a63f4f5fe944255 Mon Sep 17 00:00:00 2001
> From: Ian Jackson
> Date: Mon, 14 Oct 2019 17:59:00 +0100
> Subject: [PATCH] squash! libxl: Move shadow_memkb and iommu_memkb defaulting
> into libxl
>
> ---
> v4: Provide a fallback default for iommu_memkb too, for old callers.
> ---
> tools/libxl/libxl_create.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 7423bedf7d..b3951a2423 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -229,6 +229,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
> libxl__arch_domain_build_info_setdefault(gc, b_info);
> libxl_defbool_setdefault(_info->dm_restrict, false);
>
> +if (b_info->iommu_memkb == LIBXL_MEMKB_DEFAULT)
> +/* Normally defaulted in libxl__domain_create_info_setdefault */
> +b_info->iommu_memkb = 0;
> +
> switch (b_info->type) {
> case LIBXL_DOMAIN_TYPE_HVM:
> if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] arm/gic: Make sense of assertions
From: Andrii Anisov
ARM Compiler complains about assertion conditions being always true,
because sgi is of enum type what has all its values under 16.
In order to preserve those asserts, specify the available SGI number
right in the enum and use it for the assertions. This also eliminates
nasty hardcoded values.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/gic.c| 6 +++---
xen/include/asm-arm/gic.h | 2 ++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 113655a..bf373d7 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -294,7 +294,7 @@ void __init gic_init(void)
void send_SGI_mask(const cpumask_t *cpumask, enum gic_sgi sgi)
{
-ASSERT(sgi < 16); /* There are only 16 SGIs */
+ASSERT(sgi < NUMBER_OF_GIC_SGIS);
gic_hw_ops->send_SGI(sgi, SGI_TARGET_LIST, cpumask);
}
@@ -306,14 +306,14 @@ void send_SGI_one(unsigned int cpu, enum gic_sgi sgi)
void send_SGI_self(enum gic_sgi sgi)
{
-ASSERT(sgi < 16); /* There are only 16 SGIs */
+ASSERT(sgi < NUMBER_OF_GIC_SGIS);
gic_hw_ops->send_SGI(sgi, SGI_TARGET_SELF, NULL);
}
void send_SGI_allbutself(enum gic_sgi sgi)
{
- ASSERT(sgi < 16); /* There are only 16 SGIs */
+ ASSERT(sgi < NUMBER_OF_GIC_SGIS);
gic_hw_ops->send_SGI(sgi, SGI_TARGET_OTHERS, NULL);
}
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 793d324..5b72388 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -280,6 +280,8 @@ enum gic_sgi {
GIC_SGI_EVENT_CHECK = 0,
GIC_SGI_DUMP_STATE = 1,
GIC_SGI_CALL_FUNCTION = 2,
+/* There are only 16 SGIs */
+NUMBER_OF_GIC_SGIS = 16
};
/* SGI irq mode types */
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-next test] 142738: tolerable FAIL
flight 142738 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/142738/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-examine 8 reboot fail like 142709 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail like 142709 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail like 142709 test-amd64-i386-libvirt 7 xen-boot fail like 142709 test-amd64-i386-xl-raw7 xen-boot fail like 142709 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail like 142709 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail like 142709 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail like 142709 test-amd64-i386-xl-xsm7 xen-boot fail like 142709 test-amd64-i386-libvirt-xsm 7 xen-boot fail like 142709 test-amd64-i386-xl-shadow 7 xen-boot fail like 142709 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-bootfail like 142709 test-amd64-i386-freebsd10-i386 7 xen-bootfail like 142709 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 142709 test-amd64-i386-xl7 xen-boot fail like 142709 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail like 142709 test-amd64-i386-pair 10 xen-boot/src_hostfail like 142709 test-amd64-i386-pair 11 xen-boot/dst_hostfail like 142709 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-bootfail like 142709 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail like 142709 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail like 142709 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail like 142709 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail like 142709 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail like 142709 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail like 142709 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail like 142709 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail like 142709 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail like 142709 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail like 142709 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail like 142709 test-amd64-i386-xl-pvshim 7 xen-boot fail like 142709 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail like 142709 test-amd64-i386-freebsd10-amd64 7 xen-boot fail like 142709 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142709 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 142709 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142709 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142709 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 142709 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142709 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never
[Xen-devel] [ovmf test] 142749: regressions - FAIL
flight 142749 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/142749/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423 version targeted for testing: ovmf a1f94045ffe9218ec438c4d23980de4243d21cd0 baseline version: ovmf 410c4d00d9f7e369d1ce183e9e8de98cb59c4d20 Last test of basis 142423 2019-10-08 01:39:34 Z7 days Failing since142455 2019-10-08 19:21:52 Z6 days 11 attempts Testing same since 142733 2019-10-14 07:49:48 Z0 days2 attempts People who touched revisions under test: Ard Biesheuvel Bob Feng Feng, Bob C Jiewen Yao Laszlo Ersek Pete Batard jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 945 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
