Re: [Qemu-devel] target-alpha mttcg success
Richard Henderson writes: >> PID USER PR NIVIRTRES S P %CPU %MEM TIME+ COMMAND >> 7817 rth 20 0 5304360 712404 R 3 94.4 9.1 2:45.21 qemu-system-alp >> 7819 rth 20 0 5304360 712404 R 1 90.7 9.1 2:01.84 qemu-system-alp >> 7818 rth 20 0 5304360 712404 R 2 90.1 9.1 2:04.52 qemu-system-alp >> 7820 rth 20 0 5304360 712404 R 0 89.4 9.1 1:49.37 qemu-system-alp >> 7811 rth 20 0 5304360 712404 S 1 9.6 9.1 0:10.76 qemu-system-alp > > Whee! During a guest make -j4 build of glibc. \o/ > > On top of Alex's latest patch set all that is required for basic success is an > update to the alpha bios. Which until today didn't support smp at all. > > There does appear to be a problem with delivery of ISA interrupts for smp, > regardless whether mttcg is enabled or not, though PCI interrupts are working > fine. This appears in that both serial console and ps2 keyboard are > non-responsive, but one can ssh into the guest. Which doesn't make a whole > lot > of sense. More debugging required, I suppose. Hmm weird. I was helping Pranith with debugging one of his aarch64 guest setups under TCG and it seemed to be loosing IRQs, I could see level=1 breakpoints being hit in qemu_set_irq but no delivery of the IRQ to the CPU. Unfortunately I had to head home before we got to the bottom of it but I wonder if it is related. As far as the core code is concerned IRQ updates should be protected by the BQL. > > I'll post the palcode update once the mttcg patch set is merged. > > > r~ Good stuff ;-) -- Alex Bennée
[Qemu-devel] [Bug 1338591] Re: Cursor jumps on shape change with vmware vga
Setting SDL_VIDEO_X11_DGAMOUSE=0 environment variable works around this problem. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1338591 Title: Cursor jumps on shape change with vmware vga Status in QEMU: New Bug description: I launch QEMU with the following command line: qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm The guest OS is Windows XP. To reproduce the problem, do this: 0. Make sure guest is WinXP (don't know if it's really necessary), use vmware VGA 1. Set mouse cursor theme to default black&white theme, i.e. that without any translucency etc. 2. Open a text editor, e.g. built-in notepad 3. Move the cursor inside text entry widget 4. See the cursor jumping away. You basically can't enter the cursor there. This also reproduces with MS Word 2003 even with oxy-white cursor theme (i.e. that with translucency) — seems Word uses its plain black&transparent cursor for I-beam cursor. This doesn't happen with other VGAs, i.e. cirrus and std. I used qemu git master to test this. qemu-system-i386 --version reports version 2.0.90, git describe says v2.1.0-rc0-1-g9d9de25. This also happened in earlier QEMU versions, like 1.5.x and older. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1338591/+subscriptions
Re: [Qemu-devel] target-alpha mttcg success
On 11/13/2016 10:39 AM, Alex Bennée wrote: There does appear to be a problem with delivery of ISA interrupts for smp, regardless whether mttcg is enabled or not, though PCI interrupts are working fine. This appears in that both serial console and ps2 keyboard are non-responsive, but one can ssh into the guest. Which doesn't make a whole lot of sense. More debugging required, I suppose. Hmm weird. I was helping Pranith with debugging one of his aarch64 guest setups under TCG and it seemed to be loosing IRQs, I could see level=1 breakpoints being hit in qemu_set_irq but no delivery of the IRQ to the CPU. Unfortunately I had to head home before we got to the bottom of it but I wonder if it is related. Interesting. Please keep me in the loop on that one. As far as the core code is concerned IRQ updates should be protected by the BQL. Good, that confirms what I remembered on the subject. r~
Re: [Qemu-devel] Crashing in tcp_close
On 12/11/2016 10:44, Samuel Thibault wrote: Oops, sorry, my patch was completely bogus, here is a proper one. Excellent. I've run the original build process 18 times (each run takes about 25 minutes) without valgrind, and it hasn't crashed once. So this looks good. Thank you! Regards, Brian.
Re: [Qemu-devel] [V6, 2/7] nios2: Add architecture emulation support
On 11/13/2016 12:25 AM, Guenter Roeck wrote:
> Hi Marek,
Hi!
> On 11/12/2016 01:50 PM, Marek Vasut wrote:
>> On 11/07/2016 08:54 PM, Guenter Roeck wrote:
>>> Hi Marek,
>>>
>>> On 11/07/2016 10:14 AM, Marek Vasut wrote:
On 11/07/2016 04:58 AM, Guenter Roeck wrote:
> On Tue, Oct 25, 2016 at 09:57:43PM +0200, Marek Vasut wrote:
>> From: Chris Wulff
>>
>> Add support for emulating Altera NiosII R1 architecture into qemu.
>> This patch is based on previous work by Chris Wulff from 2012 and
>> updated to latest mainline QEMU.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Chris Wulff
>> Cc: Jeff Da Silva
>> Cc: Ley Foon Tan
>> Cc: Sandra Loosemore
>> Cc: Yves Vandervennet
>> ---
>> V3: Thorough cleanup, deal with the review comments all over the
>> place
>> V4: - Use extract32()
>> - Fix gen_goto_tb() , suppress tcg_gen_goto_tb()
>> - Clean up gen_check_supervisor() helper
>> - Use TCGMemOp type for flags
>> - Drop jump labels from wrctl/rdctl
>> - More TCG cleanup
>> V5: - Simplify load/store handling
>> - Handle loads into R_ZERO from protected page, add comment
>> V6: - Fix division opcode handling
>> - Add missing disas handling
>> - V5 review comments cleanup
>> ---
> [ ... ]
>
>> diff --git a/target-nios2/cpu.h b/target-nios2/cpu.h
>> new file mode 100644
>> index 000..17c9a0f
> [ ... ]
>
>> +static inline void cpu_get_tb_cpu_state(CPUNios2State *env,
>> target_ulong *pc,
>> +target_ulong *cs_base,
>> uint32_t *flags)
>> +{
>> +*pc = env->regs[R_PC];
>> +*cs_base = 0;
>> +*flags = (env->regs[CR_STATUS] & (CR_STATUS_EH | CR_STATUS_U));
>> +}
>> +
>> +#endif /* CPU_NIOS2_H */
>> +
>
> The empty line at the end results in a whitespace message from git.
Dropped, thanks. Is there anything else or is this patchset starting to
become acceptable ?
>>>
>>> Hard for me to say. I tried to build and run the series with the latest
>>> linux
>>> kernel (v4.9-rc4), but it is stuck in early boot. I tried with
>>> 10m50_defconfig
>>> and 10m50_devboard.dtb. gcc is 6.1.0 built with buildroot, though I also
>>> tried
>>> with toolchains from CodeSourcery. Obviously I have no idea if there
>>> is a
>>> kernel bug or a qemu bug or a problem with the command line I used.
>>>
>>> Here is my command line:
>>>
>>> qemu-system-nios2 -M 10m50-ghrd -kernel vmlinux -dtb
>>> 10m50_devboard.dtb \
>>> -append "earlycon=uart8250,mmio32,0x18001600,115200n8 console=ttyS0"
>>>
>>> This may be wrong, but the boot is stuck in an endless loop in
>>> mark_bootmem(),
>>> which seems early and odd. I tried with both vmlinux and
>>> arch/nios2/boot/vmImage,
>>> with the same results.
>>>
>>> Can you provide a working command line and kernel version, and/or
>>> directions how
>>> to create a working image if I need to run the image, for example, from
>>> u-boot ?
>>> Sorry if that is posted somewhere and I missed it.
>>
>> I guess Romain gave you something since I see you made some progress.
>> I'll have to look into that fdt loader issue.
>>
>
> Yes, WFM after
>
> diff --git a/hw/nios2/boot.c b/hw/nios2/boot.c
> index 564dbae..e0a9aff 100644
> --- a/hw/nios2/boot.c
> +++ b/hw/nios2/boot.c
> @@ -73,6 +73,11 @@ static void main_cpu_reset(void *opaque)
> }
> }
>
> +static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
> +{
> +return addr - 0xc000LL;
> +}
> +
> static int nios2_load_dtb(struct nios2_boot_info bi, const uint32_t
> ramsize,
>const char *kernel_cmdline, const char
> *dtb_filename)
> {
> @@ -97,21 +102,16 @@ static int nios2_load_dtb(struct nios2_boot_info
> bi, const uint32_t ramsize,
>
> if (bi.initrd_start) {
> qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-start",
> - bi.initrd_start);
> + translate_kernel_address(NULL,
> bi.initrd_start));
>
> qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-end",
> - bi.initrd_end);
> + translate_kernel_address(NULL,
> bi.initrd_end));
> }
>
> cpu_physical_memory_write(bi.fdt, fdt, fdt_size);
> return fdt_size;
> }
>
> -static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
> -{
> -return addr - 0xc000LL;
> -}
> -
> void nios2_load_kernel(Nios2CPU *cpu, hwaddr ddr_base,
>
>
> This is my command line, running your patch series plus the above fixup
> on top of
> the qemu master branch:
Uhm, how could that patch fix the DT passing for you ? I am still
looking into the DT passing, that's quite odd.
> qemu-system-nios2 -M 10m50-ghrd \
> -kernel vmlinux -no-reboot \
> -dtb 10m50_devboard.dtb \
> --append "rdinit=/sbin/init" \
>
Re: [Qemu-devel] [V6, 2/7] nios2: Add architecture emulation support
On 11/13/2016 01:01 PM, Marek Vasut wrote:
> On 11/13/2016 12:25 AM, Guenter Roeck wrote:
>> Hi Marek,
>
> Hi!
>
>> On 11/12/2016 01:50 PM, Marek Vasut wrote:
>>> On 11/07/2016 08:54 PM, Guenter Roeck wrote:
Hi Marek,
On 11/07/2016 10:14 AM, Marek Vasut wrote:
> On 11/07/2016 04:58 AM, Guenter Roeck wrote:
>> On Tue, Oct 25, 2016 at 09:57:43PM +0200, Marek Vasut wrote:
>>> From: Chris Wulff
>>>
>>> Add support for emulating Altera NiosII R1 architecture into qemu.
>>> This patch is based on previous work by Chris Wulff from 2012 and
>>> updated to latest mainline QEMU.
>>>
>>> Signed-off-by: Marek Vasut
>>> Cc: Chris Wulff
>>> Cc: Jeff Da Silva
>>> Cc: Ley Foon Tan
>>> Cc: Sandra Loosemore
>>> Cc: Yves Vandervennet
>>> ---
>>> V3: Thorough cleanup, deal with the review comments all over the
>>> place
>>> V4: - Use extract32()
>>> - Fix gen_goto_tb() , suppress tcg_gen_goto_tb()
>>> - Clean up gen_check_supervisor() helper
>>> - Use TCGMemOp type for flags
>>> - Drop jump labels from wrctl/rdctl
>>> - More TCG cleanup
>>> V5: - Simplify load/store handling
>>> - Handle loads into R_ZERO from protected page, add comment
>>> V6: - Fix division opcode handling
>>> - Add missing disas handling
>>> - V5 review comments cleanup
>>> ---
>> [ ... ]
>>
>>> diff --git a/target-nios2/cpu.h b/target-nios2/cpu.h
>>> new file mode 100644
>>> index 000..17c9a0f
>> [ ... ]
>>
>>> +static inline void cpu_get_tb_cpu_state(CPUNios2State *env,
>>> target_ulong *pc,
>>> +target_ulong *cs_base,
>>> uint32_t *flags)
>>> +{
>>> +*pc = env->regs[R_PC];
>>> +*cs_base = 0;
>>> +*flags = (env->regs[CR_STATUS] & (CR_STATUS_EH | CR_STATUS_U));
>>> +}
>>> +
>>> +#endif /* CPU_NIOS2_H */
>>> +
>>
>> The empty line at the end results in a whitespace message from git.
>
> Dropped, thanks. Is there anything else or is this patchset starting to
> become acceptable ?
>
Hard for me to say. I tried to build and run the series with the latest
linux
kernel (v4.9-rc4), but it is stuck in early boot. I tried with
10m50_defconfig
and 10m50_devboard.dtb. gcc is 6.1.0 built with buildroot, though I also
tried
with toolchains from CodeSourcery. Obviously I have no idea if there
is a
kernel bug or a qemu bug or a problem with the command line I used.
Here is my command line:
qemu-system-nios2 -M 10m50-ghrd -kernel vmlinux -dtb
10m50_devboard.dtb \
-append "earlycon=uart8250,mmio32,0x18001600,115200n8 console=ttyS0"
This may be wrong, but the boot is stuck in an endless loop in
mark_bootmem(),
which seems early and odd. I tried with both vmlinux and
arch/nios2/boot/vmImage,
with the same results.
Can you provide a working command line and kernel version, and/or
directions how
to create a working image if I need to run the image, for example, from
u-boot ?
Sorry if that is posted somewhere and I missed it.
>>>
>>> I guess Romain gave you something since I see you made some progress.
>>> I'll have to look into that fdt loader issue.
>>>
>>
>> Yes, WFM after
>>
>> diff --git a/hw/nios2/boot.c b/hw/nios2/boot.c
>> index 564dbae..e0a9aff 100644
>> --- a/hw/nios2/boot.c
>> +++ b/hw/nios2/boot.c
>> @@ -73,6 +73,11 @@ static void main_cpu_reset(void *opaque)
>> }
>> }
>>
>> +static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
>> +{
>> +return addr - 0xc000LL;
>> +}
>> +
>> static int nios2_load_dtb(struct nios2_boot_info bi, const uint32_t
>> ramsize,
>>const char *kernel_cmdline, const char
>> *dtb_filename)
>> {
>> @@ -97,21 +102,16 @@ static int nios2_load_dtb(struct nios2_boot_info
>> bi, const uint32_t ramsize,
>>
>> if (bi.initrd_start) {
>> qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-start",
>> - bi.initrd_start);
>> + translate_kernel_address(NULL,
>> bi.initrd_start));
>>
>> qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-end",
>> - bi.initrd_end);
>> + translate_kernel_address(NULL,
>> bi.initrd_end));
>> }
>>
>> cpu_physical_memory_write(bi.fdt, fdt, fdt_size);
>> return fdt_size;
>> }
>>
>> -static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
>> -{
>> -return addr - 0xc000LL;
>> -}
>> -
>> void nios2_load_kernel(Nios2CPU *cpu, hwaddr ddr_base,
>>
>>
>> This is my command line, running your patch series plus the above fixup
>> on top of
>> the qemu master branch:
>
> Uhm, how could that patch fix the DT passing for you ? I am still
> loo
Re: [Qemu-devel] [PATCH v3] pcie_aer: Convert pcie_aer_init to Error
On 11/12/2016 01:37 AM, Michael S. Tsirkin wrote: On Thu, Nov 03, 2016 at 08:57:56PM +0800, Cao jin wrote: When user specify invalid property aer_log_max, device should fail to create, and report appropriate message. Signed-off-by: Cao jin Was this tested outside of make check? Yes, I just test it in command line with ioh3420 [other properties],aer_log_max=0x/0/10/-1, the results meet the expectation. -- Yours Sincerely, Cao jin
Re: [Qemu-devel] [V6, 2/7] nios2: Add architecture emulation support
Hi Marek,
On 11/13/2016 04:01 AM, Marek Vasut wrote:
diff --git a/hw/nios2/boot.c b/hw/nios2/boot.c
index 564dbae..e0a9aff 100644
--- a/hw/nios2/boot.c
+++ b/hw/nios2/boot.c
@@ -73,6 +73,11 @@ static void main_cpu_reset(void *opaque)
}
}
+static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
+{
+return addr - 0xc000LL;
+}
+
static int nios2_load_dtb(struct nios2_boot_info bi, const uint32_t
ramsize,
const char *kernel_cmdline, const char
*dtb_filename)
{
@@ -97,21 +102,16 @@ static int nios2_load_dtb(struct nios2_boot_info
bi, const uint32_t ramsize,
if (bi.initrd_start) {
qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-start",
- bi.initrd_start);
+ translate_kernel_address(NULL,
bi.initrd_start));
qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-end",
- bi.initrd_end);
+ translate_kernel_address(NULL,
bi.initrd_end));
}
cpu_physical_memory_write(bi.fdt, fdt, fdt_size);
return fdt_size;
}
-static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
-{
-return addr - 0xc000LL;
-}
-
void nios2_load_kernel(Nios2CPU *cpu, hwaddr ddr_base,
This is my command line, running your patch series plus the above fixup
on top of
the qemu master branch:
Uhm, how could that patch fix the DT passing for you ? I am still
looking into the DT passing, that's quite odd.
The problem isn't that much that dtb passing fails without the above fix,
the problem is that memory initialization fails if wrong addresses are
passed in the initrd properties (probably because the kernel tries to
access or free memory that does not exist). This results in a kernel hang
(endless loop) in memory initialization code.
Guenter
Re: [Qemu-devel] [V6, 2/7] nios2: Add architecture emulation support
On 11/13/2016 04:43 AM, Marek Vasut wrote:
On 11/13/2016 01:01 PM, Marek Vasut wrote:
On 11/13/2016 12:25 AM, Guenter Roeck wrote:
Hi Marek,
Hi!
On 11/12/2016 01:50 PM, Marek Vasut wrote:
On 11/07/2016 08:54 PM, Guenter Roeck wrote:
Hi Marek,
On 11/07/2016 10:14 AM, Marek Vasut wrote:
On 11/07/2016 04:58 AM, Guenter Roeck wrote:
On Tue, Oct 25, 2016 at 09:57:43PM +0200, Marek Vasut wrote:
From: Chris Wulff
Add support for emulating Altera NiosII R1 architecture into qemu.
This patch is based on previous work by Chris Wulff from 2012 and
updated to latest mainline QEMU.
Signed-off-by: Marek Vasut
Cc: Chris Wulff
Cc: Jeff Da Silva
Cc: Ley Foon Tan
Cc: Sandra Loosemore
Cc: Yves Vandervennet
---
V3: Thorough cleanup, deal with the review comments all over the
place
V4: - Use extract32()
- Fix gen_goto_tb() , suppress tcg_gen_goto_tb()
- Clean up gen_check_supervisor() helper
- Use TCGMemOp type for flags
- Drop jump labels from wrctl/rdctl
- More TCG cleanup
V5: - Simplify load/store handling
- Handle loads into R_ZERO from protected page, add comment
V6: - Fix division opcode handling
- Add missing disas handling
- V5 review comments cleanup
---
[ ... ]
diff --git a/target-nios2/cpu.h b/target-nios2/cpu.h
new file mode 100644
index 000..17c9a0f
[ ... ]
+static inline void cpu_get_tb_cpu_state(CPUNios2State *env,
target_ulong *pc,
+target_ulong *cs_base,
uint32_t *flags)
+{
+*pc = env->regs[R_PC];
+*cs_base = 0;
+*flags = (env->regs[CR_STATUS] & (CR_STATUS_EH | CR_STATUS_U));
+}
+
+#endif /* CPU_NIOS2_H */
+
The empty line at the end results in a whitespace message from git.
Dropped, thanks. Is there anything else or is this patchset starting to
become acceptable ?
Hard for me to say. I tried to build and run the series with the latest
linux
kernel (v4.9-rc4), but it is stuck in early boot. I tried with
10m50_defconfig
and 10m50_devboard.dtb. gcc is 6.1.0 built with buildroot, though I also
tried
with toolchains from CodeSourcery. Obviously I have no idea if there
is a
kernel bug or a qemu bug or a problem with the command line I used.
Here is my command line:
qemu-system-nios2 -M 10m50-ghrd -kernel vmlinux -dtb
10m50_devboard.dtb \
-append "earlycon=uart8250,mmio32,0x18001600,115200n8 console=ttyS0"
This may be wrong, but the boot is stuck in an endless loop in
mark_bootmem(),
which seems early and odd. I tried with both vmlinux and
arch/nios2/boot/vmImage,
with the same results.
Can you provide a working command line and kernel version, and/or
directions how
to create a working image if I need to run the image, for example, from
u-boot ?
Sorry if that is posted somewhere and I missed it.
I guess Romain gave you something since I see you made some progress.
I'll have to look into that fdt loader issue.
Yes, WFM after
diff --git a/hw/nios2/boot.c b/hw/nios2/boot.c
index 564dbae..e0a9aff 100644
--- a/hw/nios2/boot.c
+++ b/hw/nios2/boot.c
@@ -73,6 +73,11 @@ static void main_cpu_reset(void *opaque)
}
}
+static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
+{
+return addr - 0xc000LL;
+}
+
static int nios2_load_dtb(struct nios2_boot_info bi, const uint32_t
ramsize,
const char *kernel_cmdline, const char
*dtb_filename)
{
@@ -97,21 +102,16 @@ static int nios2_load_dtb(struct nios2_boot_info
bi, const uint32_t ramsize,
if (bi.initrd_start) {
qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-start",
- bi.initrd_start);
+ translate_kernel_address(NULL,
bi.initrd_start));
qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-end",
- bi.initrd_end);
+ translate_kernel_address(NULL,
bi.initrd_end));
}
cpu_physical_memory_write(bi.fdt, fdt, fdt_size);
return fdt_size;
}
-static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
-{
-return addr - 0xc000LL;
-}
-
void nios2_load_kernel(Nios2CPU *cpu, hwaddr ddr_base,
This is my command line, running your patch series plus the above fixup
on top of
the qemu master branch:
Uhm, how could that patch fix the DT passing for you ? I am still
looking into the DT passing, that's quite odd.
This patch makes the DT passing work for me, but I cannot put my finger
on why. It moves the DT a bit further in memory, that's all.
diff --git a/hw/nios2/boot.c b/hw/nios2/boot.c
index 564dbae..c9e3e69 100644
--- a/hw/nios2/boot.c
+++ b/hw/nios2/boot.c
@@ -178,7 +183,7 @@ void nios2_load_kernel(Nios2CPU *cpu, hwaddr ddr_base,
high = ddr_base + kernel_size;
}
-high = ROUND_UP(high, 1024 * 1024);
+high = ROUND_UP(high, 1024 * 1024) + 0x1;
/* If initrd is available, it goes after the kernel, aligned to
1M. */
if (initrd_filename) {
That doesn't work for me,
[Qemu-devel] [PATCH] slirp: Fix access to freed memory
if_start() goes through the slirp->if_fastq and slirp->if_batchq
list of pending messages, and accesses ifm->ifq_so->so_nqueued of its
elements if ifm->ifq_so != NULL. When freeing a socket, we thus need
to make sure that any pending message for this socket does not refer
to the socket any more.
Signed-off-by: Samuel Thibault
Tested-by: Brian Candler
---
slirp/socket.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/slirp/socket.c b/slirp/socket.c
index 280050a..6c18971 100644
--- a/slirp/socket.c
+++ b/slirp/socket.c
@@ -66,6 +66,23 @@ void
sofree(struct socket *so)
{
Slirp *slirp = so->slirp;
+ struct mbuf *ifm;
+
+ for (ifm = (struct mbuf *) slirp->if_fastq.qh_link;
+ (struct quehead *) ifm != &slirp->if_fastq;
+ ifm = ifm->ifq_next) {
+if (ifm->ifq_so == so) {
+ ifm->ifq_so = NULL;
+}
+ }
+
+ for (ifm = (struct mbuf *) slirp->if_batchq.qh_link;
+ (struct quehead *) ifm != &slirp->if_batchq;
+ ifm = ifm->ifq_next) {
+if (ifm->ifq_so == so) {
+ ifm->ifq_so = NULL;
+}
+ }
if (so->so_emu==EMU_RSH && so->extra) {
sofree(so->extra);
--
2.10.2
Re: [Qemu-devel] [V6, 2/7] nios2: Add architecture emulation support
On 11/13/2016 05:09 PM, Guenter Roeck wrote:
> Hi Marek,
>
> On 11/13/2016 04:01 AM, Marek Vasut wrote:
>>>
>>> diff --git a/hw/nios2/boot.c b/hw/nios2/boot.c
>>> index 564dbae..e0a9aff 100644
>>> --- a/hw/nios2/boot.c
>>> +++ b/hw/nios2/boot.c
>>> @@ -73,6 +73,11 @@ static void main_cpu_reset(void *opaque)
>>> }
>>> }
>>>
>>> +static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
>>> +{
>>> +return addr - 0xc000LL;
>>> +}
>>> +
>>> static int nios2_load_dtb(struct nios2_boot_info bi, const uint32_t
>>> ramsize,
>>>const char *kernel_cmdline, const char
>>> *dtb_filename)
>>> {
>>> @@ -97,21 +102,16 @@ static int nios2_load_dtb(struct nios2_boot_info
>>> bi, const uint32_t ramsize,
>>>
>>> if (bi.initrd_start) {
>>> qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-start",
>>> - bi.initrd_start);
>>> + translate_kernel_address(NULL,
>>> bi.initrd_start));
>>>
>>> qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-end",
>>> - bi.initrd_end);
>>> + translate_kernel_address(NULL,
>>> bi.initrd_end));
>>> }
>>>
>>> cpu_physical_memory_write(bi.fdt, fdt, fdt_size);
>>> return fdt_size;
>>> }
>>>
>>> -static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
>>> -{
>>> -return addr - 0xc000LL;
>>> -}
>>> -
>>> void nios2_load_kernel(Nios2CPU *cpu, hwaddr ddr_base,
>>>
>>>
>>> This is my command line, running your patch series plus the above fixup
>>> on top of
>>> the qemu master branch:
>>
>> Uhm, how could that patch fix the DT passing for you ? I am still
>> looking into the DT passing, that's quite odd.
>>
>
> The problem isn't that much that dtb passing fails without the above fix,
> the problem is that memory initialization fails if wrong addresses are
> passed in the initrd properties (probably because the kernel tries to
> access or free memory that does not exist). This results in a kernel hang
> (endless loop) in memory initialization code.
I was looking through that initcode today and through the Nios2 DTS, it
looks like quite an inconsistent mess of User and Kernel addresses used
there.
--
Best regards,
Marek Vasut
Re: [Qemu-devel] [V6, 2/7] nios2: Add architecture emulation support
On 11/13/2016 05:25 PM, Guenter Roeck wrote:
> On 11/13/2016 04:43 AM, Marek Vasut wrote:
>> On 11/13/2016 01:01 PM, Marek Vasut wrote:
>>> On 11/13/2016 12:25 AM, Guenter Roeck wrote:
Hi Marek,
>>>
>>> Hi!
>>>
On 11/12/2016 01:50 PM, Marek Vasut wrote:
> On 11/07/2016 08:54 PM, Guenter Roeck wrote:
>> Hi Marek,
>>
>> On 11/07/2016 10:14 AM, Marek Vasut wrote:
>>> On 11/07/2016 04:58 AM, Guenter Roeck wrote:
On Tue, Oct 25, 2016 at 09:57:43PM +0200, Marek Vasut wrote:
> From: Chris Wulff
>
> Add support for emulating Altera NiosII R1 architecture into qemu.
> This patch is based on previous work by Chris Wulff from 2012 and
> updated to latest mainline QEMU.
>
> Signed-off-by: Marek Vasut
> Cc: Chris Wulff
> Cc: Jeff Da Silva
> Cc: Ley Foon Tan
> Cc: Sandra Loosemore
> Cc: Yves Vandervennet
> ---
> V3: Thorough cleanup, deal with the review comments all over the
> place
> V4: - Use extract32()
> - Fix gen_goto_tb() , suppress tcg_gen_goto_tb()
> - Clean up gen_check_supervisor() helper
> - Use TCGMemOp type for flags
> - Drop jump labels from wrctl/rdctl
> - More TCG cleanup
> V5: - Simplify load/store handling
> - Handle loads into R_ZERO from protected page, add comment
> V6: - Fix division opcode handling
> - Add missing disas handling
> - V5 review comments cleanup
> ---
[ ... ]
> diff --git a/target-nios2/cpu.h b/target-nios2/cpu.h
> new file mode 100644
> index 000..17c9a0f
[ ... ]
> +static inline void cpu_get_tb_cpu_state(CPUNios2State *env,
> target_ulong *pc,
> +target_ulong *cs_base,
> uint32_t *flags)
> +{
> +*pc = env->regs[R_PC];
> +*cs_base = 0;
> +*flags = (env->regs[CR_STATUS] & (CR_STATUS_EH |
> CR_STATUS_U));
> +}
> +
> +#endif /* CPU_NIOS2_H */
> +
The empty line at the end results in a whitespace message from git.
>>>
>>> Dropped, thanks. Is there anything else or is this patchset
>>> starting to
>>> become acceptable ?
>>>
>>
>> Hard for me to say. I tried to build and run the series with the
>> latest
>> linux
>> kernel (v4.9-rc4), but it is stuck in early boot. I tried with
>> 10m50_defconfig
>> and 10m50_devboard.dtb. gcc is 6.1.0 built with buildroot, though
>> I also
>> tried
>> with toolchains from CodeSourcery. Obviously I have no idea if there
>> is a
>> kernel bug or a qemu bug or a problem with the command line I used.
>>
>> Here is my command line:
>>
>> qemu-system-nios2 -M 10m50-ghrd -kernel vmlinux -dtb
>> 10m50_devboard.dtb \
>> -append "earlycon=uart8250,mmio32,0x18001600,115200n8
>> console=ttyS0"
>>
>> This may be wrong, but the boot is stuck in an endless loop in
>> mark_bootmem(),
>> which seems early and odd. I tried with both vmlinux and
>> arch/nios2/boot/vmImage,
>> with the same results.
>>
>> Can you provide a working command line and kernel version, and/or
>> directions how
>> to create a working image if I need to run the image, for example,
>> from
>> u-boot ?
>> Sorry if that is posted somewhere and I missed it.
>
> I guess Romain gave you something since I see you made some progress.
> I'll have to look into that fdt loader issue.
>
Yes, WFM after
diff --git a/hw/nios2/boot.c b/hw/nios2/boot.c
index 564dbae..e0a9aff 100644
--- a/hw/nios2/boot.c
+++ b/hw/nios2/boot.c
@@ -73,6 +73,11 @@ static void main_cpu_reset(void *opaque)
}
}
+static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
+{
+return addr - 0xc000LL;
+}
+
static int nios2_load_dtb(struct nios2_boot_info bi, const uint32_t
ramsize,
const char *kernel_cmdline, const char
*dtb_filename)
{
@@ -97,21 +102,16 @@ static int nios2_load_dtb(struct nios2_boot_info
bi, const uint32_t ramsize,
if (bi.initrd_start) {
qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-start",
- bi.initrd_start);
+ translate_kernel_address(NULL,
bi.initrd_start));
qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-end",
- bi.initrd_end);
+ translate_kernel_address(NULL,
bi.initrd_end));
}
cpu_physical_memory_write(bi.fdt, fdt, fdt_size);
retu
Re: [Qemu-devel] [PATCH] slirp: Fix access to freed memory
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH] slirp: Fix access to freed memory
Message-id: 20161113230102.12173-1-samuel.thiba...@ens-lyon.org
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0
# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True
commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done
exit $failed
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
* [new tag]
patchew/20161113230102.12173-1-samuel.thiba...@ens-lyon.org ->
patchew/20161113230102.12173-1-samuel.thiba...@ens-lyon.org
Switched to a new branch 'test'
8fdbb81 slirp: Fix access to freed memory
=== OUTPUT BEGIN ===
fatal: unrecognized argument: --no-patch
Checking PATCH 1/1: ...
ERROR: suspect code indent for conditional statements (4, 6)
#29: FILE: slirp/socket.c:74:
+if (ifm->ifq_so == so) {
+ ifm->ifq_so = NULL;
ERROR: suspect code indent for conditional statements (4, 6)
#37: FILE: slirp/socket.c:82:
+if (ifm->ifq_so == so) {
+ ifm->ifq_so = NULL;
total: 2 errors, 0 warnings, 23 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===
Test command exited with code: 1
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org
Re: [Qemu-devel] [PATCH] slirp: Fix access to freed memory
Hello,
Note:
no-re...@patchew.org, on Sun 13 Nov 2016 15:13:47 -0800, wrote:
> Your series seems to have some coding style problems. See output below for
> more information:
>
> === OUTPUT BEGIN ===
> fatal: unrecognized argument: --no-patch
> Checking PATCH 1/1: ...
> ERROR: suspect code indent for conditional statements (4, 6)
> #29: FILE: slirp/socket.c:74:
> +if (ifm->ifq_so == so) {
> + ifm->ifq_so = NULL;
>
> ERROR: suspect code indent for conditional statements (4, 6)
> #37: FILE: slirp/socket.c:82:
> +if (ifm->ifq_so == so) {
> + ifm->ifq_so = NULL;
This is due to that portion of the slirp code using 2-space indentation
instead of 4-space indentation.
Samuel
Re: [Qemu-devel] [Qemu-ppc] [RFC 16/17] ppc: Remove counter-productive "sanity checks" in migration
On 12/11/16 05:13, Greg Kurz wrote:
> On Tue, 8 Nov 2016 16:31:08 +1100
> David Gibson wrote:
>
>> On Fri, Nov 04, 2016 at 04:52:39PM +1100, Alexey Kardashevskiy wrote:
>>> On 30/10/16 22:12, David Gibson wrote:
When vmstate for the ppc cpu was introduced in a90db158 "target-ppc:
Convert ppc cpu savevm to VMStateDescription", several "sanity check"
fields were included, verifying that certain cpu parameters matched between
source and destination.
This turns out not to have been a good idea. For one thing it's redundant
with existing checks for a compatible cpu version at either end. But more
importantly the insns_flags and insns_flags2 checks actively break things:
they expose what's essentially an internal TCG implementation detail in the
migration stream. That means that when new instruction classes are added
or rearranged, migration can break.
This removes these ill-considered sanity checks.
Signed-off-by: David Gibson
---
target-ppc/machine.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/target-ppc/machine.c b/target-ppc/machine.c
index 62b9e94..453ef0a 100644
--- a/target-ppc/machine.c
+++ b/target-ppc/machine.c
@@ -602,10 +602,10 @@ const VMStateDescription vmstate_ppc_cpu = {
/* FIXME: access_type? */
/* Sanity checking */
-VMSTATE_UINTTL_EQUAL(env.msr_mask, PowerPCCPU),
-VMSTATE_UINT64_EQUAL(env.insns_flags, PowerPCCPU),
-VMSTATE_UINT64_EQUAL(env.insns_flags2, PowerPCCPU),
-VMSTATE_UINT32_EQUAL(env.nb_BATs, PowerPCCPU),
+VMSTATE_UNUSED(sizeof(target_ulong) /* msr_mask */
+ + sizeof(uint64_t) /* insns_flags */
+ + sizeof(uint64_t) /* insns_flags2 */
+ + sizeof(uint32_t)), /* nb_BATs */
>>>
>>>
>>> This breaks migration to older QEMU:
>>>
>>> 25055@1478238734.537761:vmstate_load_field_error field "env.msr_mask" load
>>> failed, ret = -22
>>
>> Again, I don't think we generally support backwards migration.
>>
>> That said, it would be nice here to do a "set to this field on
>> ourgoing migration, but ignore on incoming migration". Do you know a
>> way to do that?
>>
>
> This doesn't exist in vmstate but it is certainly doable. An alternative
> would be to always send the fields, but have the destination to use
> pre_load and post_load callbacks to preserve its state.
A simpler way would be:
1. add a copy for each field (s/msr_mask/mig_msr_mask/),
2. get rid of _EQUAL bits,
3. implement .pre_save callback which would initialize mig_xxx
And that's it, .pre_load/.post_load is not needed.
>
>> a
>>>
>>>
>>>
VMSTATE_END_OF_LIST()
},
.subsections = (const VMStateDescription*[]) {
>>>
>>>
>>
>
--
Alexey
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2] migration: fix missing assignment for has_x_checkpoint_delay
ping ? On 2016/11/2 15:42, zhanghailiang wrote: We forgot to assign true to params->has_x_checkpoint_delay parameter in qmp_query_migrate_parameters. Without this, qmp command 'query-migrate-parameters' doesn't show the default value for x-checkpoint-delay option. This also fixes the fact that HMP was relying on unspecified behavior by reading x_checkpoint_delay without checking has_x_checkpoint_delay. Signed-off-by: zhanghailiang Reviewed-by: Eric Blake --- v2: - fix the commit message as Eric sugguested. --- hmp.c | 1 + migration/migration.c | 1 + 2 files changed, 2 insertions(+) diff --git a/hmp.c b/hmp.c index b5e3f54..02103df 100644 --- a/hmp.c +++ b/hmp.c @@ -318,6 +318,7 @@ void hmp_info_migrate_parameters(Monitor *mon, const QDict *qdict) monitor_printf(mon, " %s: %" PRId64 " milliseconds", MigrationParameter_lookup[MIGRATION_PARAMETER_DOWNTIME_LIMIT], params->downtime_limit); +assert(params->has_x_checkpoint_delay); monitor_printf(mon, " %s: %" PRId64, MigrationParameter_lookup[MIGRATION_PARAMETER_X_CHECKPOINT_DELAY], params->x_checkpoint_delay); diff --git a/migration/migration.c b/migration/migration.c index e331f28..f498ab8 100644 --- a/migration/migration.c +++ b/migration/migration.c @@ -593,6 +593,7 @@ MigrationParameters *qmp_query_migrate_parameters(Error **errp) params->max_bandwidth = s->parameters.max_bandwidth; params->has_downtime_limit = true; params->downtime_limit = s->parameters.downtime_limit; +params->has_x_checkpoint_delay = true; params->x_checkpoint_delay = s->parameters.x_checkpoint_delay; return params;
Re: [Qemu-devel] [PATCH v2] qapi-schema: clarify 'colo' state for MigrationStatus
ping ? Anyone pick this up? On 2016/11/2 22:04, Eric Blake wrote: On 11/02/2016 02:44 AM, zhanghailiang wrote: VM can not get into colo state unless users enable 'x-colo' capability for migration, Here it is necessary to clarify this. Suggested-by: Eric Blake Signed-off-by: zhanghailiang --- v2: - Clarify colo state for RunState too as Eric suggested. --- qapi-schema.json | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) Reviewed-by: Eric Blake
Re: [Qemu-devel] [PATCH v11 10/22] vfio iommu type1: Add support for mediated devices
* Kirti Wankhede [2016-11-05 02:40:44 +0530]:
Hi Kirti,
[...]
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 8d64528dcc22..e511073446a0 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
[...]
> +static int vfio_pfn_account(struct vfio_addr_space *addr_space,
> + unsigned long pfn)
> +{
> + struct vfio_pfn *p;
> + int ret = 1;
> +
> + mutex_lock(&addr_space->pfn_list_lock);
> + p = vfio_find_pfn(addr_space, pfn);
> + if (p)
> + ret = 0;
> + mutex_unlock(&addr_space->pfn_list_lock);
> + return ret;
> +}
We could save a local variables(@ret) here by:
return (p ? 0 : 1);
> +
> struct vwork {
> struct mm_struct*mm;
> longnpage;
[...]
--
Dong Jia
[Qemu-devel] [PULL V2 3/3] net: fix sending of data with -net socket, listen backend
From: "Daniel P. Berrange"
The use of -net socket,listen was broken in the following
commit
commit 16a3df403b10c4ac347159e39005fd520b2648bb
Author: Zhang Chen
Date: Fri May 13 15:35:19 2016 +0800
net/net: Add SocketReadState for reuse codes
This function is from net/socket.c, move it to net.c and net.h.
Add SocketReadState to make others reuse net_fill_rstate().
suggestion from jason.
This refactored the state out of NetSocketState into a
separate SocketReadState. This refactoring requires
that a callback is provided to be triggered upon
completion of a packet receive from the guest.
The patch only registered this callback in the codepaths
hit by -net socket,connect, not -net socket,listen. So
as a result packets sent by the guest in the latter case
get dropped on the floor.
This bug is hidden because net_fill_rstate() silently
does nothing if the callback is not set.
This patch adds in the middle callback registration
and also adds an assert so that QEMU aborts if there
are any other codepaths hit which are missing the
callback.
Signed-off-by: Daniel P. Berrange
Reviewed-by: Zhang Chen
Signed-off-by: Jason Wang
---
net/net.c| 5 ++---
net/socket.c | 1 +
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/net.c b/net/net.c
index ec984bf..939fe31 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1653,9 +1653,8 @@ int net_fill_rstate(SocketReadState *rs, const uint8_t
*buf, int size)
if (rs->index >= rs->packet_len) {
rs->index = 0;
rs->state = 0;
-if (rs->finalize) {
-rs->finalize(rs);
-}
+assert(rs->finalize);
+rs->finalize(rs);
}
break;
}
diff --git a/net/socket.c b/net/socket.c
index 982c8de..fe3547b 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -511,6 +511,7 @@ static int net_socket_listen_init(NetClientState *peer,
s->fd = -1;
s->listen_fd = ret;
s->nc.link_down = true;
+net_socket_rs_init(&s->rs, net_socket_rs_finalize);
qemu_set_fd_handler(s->listen_fd, net_socket_accept, NULL, s);
qapi_free_SocketAddress(saddr);
--
2.7.4
[Qemu-devel] [PULL V2 1/3] record/replay: add network support
From: Pavel Dovgalyuk
This patch adds support of recording and replaying network packets in
irount rr mode.
Record and replay for network interactions is performed with the network filter.
Each backend must have its own instance of the replay filter as follows:
-netdev user,id=net1 -device rtl8139,netdev=net1
-object filter-replay,id=replay,netdev=net1
Replay network filter is used to record and replay network packets. While
recording the virtual machine this filter puts all packets coming from
the outer world into the log. In replay mode packets from the log are
injected into the network device. All interactions with network backend
in replay mode are disabled.
v5 changes:
- using iov_to_buf function instead of loop
Signed-off-by: Pavel Dovgalyuk
Signed-off-by: Jason Wang
---
docs/replay.txt | 14 +++
include/sysemu/replay.h | 12 ++
net/Makefile.objs| 1 +
net/filter-replay.c | 92 ++
replay/Makefile.objs | 1 +
replay/replay-events.c | 11 +
replay/replay-internal.h | 10 +
replay/replay-net.c | 102 +++
replay/replay.c | 2 +-
vl.c | 3 +-
10 files changed, 246 insertions(+), 2 deletions(-)
create mode 100644 net/filter-replay.c
create mode 100644 replay/replay-net.c
diff --git a/docs/replay.txt b/docs/replay.txt
index 779c6c0..347b2ff 100644
--- a/docs/replay.txt
+++ b/docs/replay.txt
@@ -195,3 +195,17 @@ Queue is flushed at checkpoints and information about
processed requests
is recorded to the log. In replay phase the queue is matched with
events read from the log. Therefore block devices requests are processed
deterministically.
+
+Network devices
+---
+
+Record and replay for network interactions is performed with the network
filter.
+Each backend must have its own instance of the replay filter as follows:
+ -netdev user,id=net1 -device rtl8139,netdev=net1
+ -object filter-replay,id=replay,netdev=net1
+
+Replay network filter is used to record and replay network packets. While
+recording the virtual machine this filter puts all packets coming from
+the outer world into the log. In replay mode packets from the log are
+injected into the network device. All interactions with network backend
+in replay mode are disabled.
diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index f80d6d2..abb35ca 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -39,6 +39,8 @@ enum ReplayCheckpoint {
};
typedef enum ReplayCheckpoint ReplayCheckpoint;
+typedef struct ReplayNetState ReplayNetState;
+
extern ReplayMode replay_mode;
/* Replay process control functions */
@@ -137,4 +139,14 @@ void replay_char_read_all_save_error(int res);
/*! Writes character read_all execution result into the replay log. */
void replay_char_read_all_save_buf(uint8_t *buf, int offset);
+/* Network */
+
+/*! Registers replay network filter attached to some backend. */
+ReplayNetState *replay_register_net(NetFilterState *nfs);
+/*! Unregisters replay network filter. */
+void replay_unregister_net(ReplayNetState *rns);
+/*! Called to write network packet to the replay log. */
+void replay_net_packet_event(ReplayNetState *rns, unsigned flags,
+ const struct iovec *iov, int iovcnt);
+
#endif
diff --git a/net/Makefile.objs b/net/Makefile.objs
index 2a80df5..2e2fd43 100644
--- a/net/Makefile.objs
+++ b/net/Makefile.objs
@@ -19,3 +19,4 @@ common-obj-y += filter-mirror.o
common-obj-y += colo-compare.o
common-obj-y += colo.o
common-obj-y += filter-rewriter.o
+common-obj-y += filter-replay.o
diff --git a/net/filter-replay.c b/net/filter-replay.c
new file mode 100644
index 000..cff65f8
--- /dev/null
+++ b/net/filter-replay.c
@@ -0,0 +1,92 @@
+/*
+ * filter-replay.c
+ *
+ * Copyright (c) 2010-2016 Institute for System Programming
+ * of the Russian Academy of Sciences.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "clients.h"
+#include "qapi/error.h"
+#include "qemu-common.h"
+#include "qemu/error-report.h"
+#include "qemu/iov.h"
+#include "qemu/log.h"
+#include "qemu/timer.h"
+#include "qapi/visitor.h"
+#include "net/filter.h"
+#include "sysemu/replay.h"
+
+#define TYPE_FILTER_REPLAY "filter-replay"
+
+#define FILTER_REPLAY(obj) \
+OBJECT_CHECK(NetFilterReplayState, (obj), TYPE_FILTER_REPLAY)
+
+struct NetFilterReplayState {
+NetFilterState nfs;
+ReplayNetState *rns;
+};
+typedef struct NetFilterReplayState NetFilterReplayState;
+
+static ssize_t filter_replay_receive_iov(NetFilterState *nf,
+ NetClientState *sndr,
+ unsigned flags,
+ const struct iovec *iov,
+
[Qemu-devel] [PULL V2 2/3] net: skip virtio-net config of deleted nic's peers
From: Yuri Benditovich
https://bugzilla.redhat.com/show_bug.cgi?id=1373816
qemu core dump happens during repetitive unpug-plug
with multiple queues and Windows RSS-capable guest.
If back-end delete requested during virtio-net device
initialization, driver still can try configure the device
for multiple queues. The virtio-net device is expected
to be removed as soon as the initialization is done.
Signed-off-by: Yuri Benditovich
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 06bfe4b..77a4fae 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -508,6 +508,10 @@ static void virtio_net_set_queues(VirtIONet *n)
int i;
int r;
+if (n->nic->peer_deleted) {
+return;
+}
+
for (i = 0; i < n->max_queues; i++) {
if (i < n->curr_queues) {
r = peer_attach(n, i);
--
2.7.4
Re: [Qemu-devel] [RFC 12/17] ppc: Migrate compatibility mode
On Thu, Nov 10, 2016 at 05:55:36PM -0600, Michael Roth wrote:
> Quoting David Gibson (2016-11-09 19:59:37)
> > On Tue, Nov 08, 2016 at 04:51:10PM +1100, Alexey Kardashevskiy wrote:
> > > On 08/11/16 16:19, David Gibson wrote:
> > > > On Fri, Nov 04, 2016 at 04:58:47PM +1100, Alexey Kardashevskiy wrote:
> > > >> On 30/10/16 22:12, David Gibson wrote:
> > > >>> Server-class POWER CPUs can be put into several compatibility modes.
> > > >>> These
> > > >>> can be specified on the command line, or negotiated by the guest
> > > >>> during
> > > >>> boot.
> > > >>>
> > > >>> Currently we don't migrate the compatibility mode, which means after a
> > > >>> migration the guest will revert to running with whatever compatibility
> > > >>> mode (or none) specified on the command line.
> > > >>>
> > > >>> With the limited range of CPUs currently used, this doesn't usually
> > > >>> cause
> > > >>> a problem, but it could. Fix this by adding the compatibility mode
> > > >>> (if
> > > >>> set) to the migration stream.
> > > >>>
> > > >>> Signed-off-by: David Gibson
> > > >>> ---
> > > >>> target-ppc/machine.c | 34 ++
> > > >>> 1 file changed, 34 insertions(+)
> > > >>>
> > > >>> diff --git a/target-ppc/machine.c b/target-ppc/machine.c
> > > >>> index 4820f22..5d87ff6 100644
> > > >>> --- a/target-ppc/machine.c
> > > >>> +++ b/target-ppc/machine.c
> > > >>> @@ -9,6 +9,7 @@
> > > >>> #include "mmu-hash64.h"
> > > >>> #include "migration/cpu.h"
> > > >>> #include "exec/exec-all.h"
> > > >>> +#include "qapi/error.h"
> > > >>>
> > > >>> static int cpu_load_old(QEMUFile *f, void *opaque, int version_id)
> > > >>> {
> > > >>> @@ -176,6 +177,20 @@ static int cpu_post_load(void *opaque, int
> > > >>> version_id)
> > > >>> * software has to take care of running QEMU in a compatible
> > > >>> mode.
> > > >>> */
> > > >>> env->spr[SPR_PVR] = env->spr_cb[SPR_PVR].default_value;
> > > >>> +
> > > >>> +#if defined(TARGET_PPC64)
> > > >>> +if (cpu->compat_pvr) {
> > > >>> +Error *local_err = NULL;
> > > >>> +
> > > >>> +ppc_set_compat(cpu, cpu->compat_pvr, &local_err);
> > > >>> +if (local_err) {
> > > >>> +error_report_err(local_err);
> > > >>> +error_free(local_err);
> > > >>> +return -1;
> > > >>> +}
> > > >>> +}
> > > >>> +#endif
> > > >>> +
> > > >>> env->lr = env->spr[SPR_LR];
> > > >>> env->ctr = env->spr[SPR_CTR];
> > > >>> cpu_write_xer(env, env->spr[SPR_XER]);
> > > >>> @@ -528,6 +543,24 @@ static const VMStateDescription vmstate_tlbmas =
> > > >>> {
> > > >>> }
> > > >>> };
> > > >>>
> > > >>> +static bool compat_needed(void *opaque)
> > > >>> +{
> > > >>> +PowerPCCPU *cpu = opaque;
> > > >>> +
> > > >>> +return cpu->compat_pvr != 0;
> > > >>
> > > >>
> > > >> Finally got to trying how this affects migration :)
> > > >>
> > > >> This breaks migration to QEMU <=2.7, and it should not at least when
> > > >> both
> > > >> source and destination are running with -cpu host,compat=power7.
> > > >
> > > > IIUC, we don't generally try to maintain backwards migration, even for
> > > > old machine types.
> > >
> > >
> > > I thought the opposite - we generally try to maintain it, this is pretty
> > > much why we use these subsections in cases like this; otherwise you could
> > > just add a new field and bump the vmstate_ppc_cpu.version.
> >
> > Hm, I guess that's true. We do at least try to allow backwards
> > migration, we just don't insist on it. The example here partially
> > suceeds - it will allow backwards migration for CPUs in raw mode.
>
> What if we changed the condition to cpu->compat_pvr != cpu->max_compat?
> Assuming each end sets compat=powerX (which seems like a reasonable
> requirement for migration), it seems like in most cases the guest would end
> up negotiating max_compat anyway. It's only in cases where it doesn't that we
> end up in an ambiguous state.
So, since I've already given up on backwards migration in other cases,
I've changed this in my next version to simply (cpu->vhyp != NULL), so
the compat mode (including raw) is always transferred on pseries.
> Newer QEMU would guard against this by migrating it's compat_pvr
> accordingly (which will probably become more important with p9 guests
> potentially running older kernels), but otherwise it seems like we could
> maintain backwards migration in most cases.
>
> Although with the proposed version bump for vmstate_spapr_pci I guess
> the discussion is somewhat moot unless we decide we rely want to
> maintain backward migration...
Not enough that it's worth the considerable extra difficulty it
entails, I think.
>
> >
> > I'll look at just bumping the version instead.
> >
> > >
> > >
> > > >
> > > >>
> > > >>
> > > >>> +}
> > > >>> +
> > > >>> +static const VMStateDescription vmstate_compat = {
> > > >>> +.name = "cpu/compat",
> > > >>> +.version_id = 1,
> > > >>> +
[Qemu-devel] [PULL V2 0/3] Net patches
The following changes since commit 83c83f9a5266ff113060f887f106a47920fa6974: Merge remote-tracking branch 'bonzini/tags/for-upstream' into staging (2016-11-11 12:51:50 +) are available in the git repository at: https://github.com/jasowang/qemu.git tags/net-pull-request for you to fetch changes up to 73c46860454f8e43d1679d1367552d15a66b7790: net: fix sending of data with -net socket, listen backend (2016-11-14 10:26:22 +0800) Changes from V1: - no change, V1 misses the list Daniel P. Berrange (1): net: fix sending of data with -net socket, listen backend Pavel Dovgalyuk (1): record/replay: add network support Yuri Benditovich (1): net: skip virtio-net config of deleted nic's peers docs/replay.txt | 14 +++ hw/net/virtio-net.c | 4 ++ include/sysemu/replay.h | 12 ++ net/Makefile.objs| 1 + net/filter-replay.c | 92 ++ net/net.c| 5 +-- net/socket.c | 1 + replay/Makefile.objs | 1 + replay/replay-events.c | 11 + replay/replay-internal.h | 10 + replay/replay-net.c | 102 +++ replay/replay.c | 2 +- vl.c | 3 +- 13 files changed, 253 insertions(+), 5 deletions(-) create mode 100644 net/filter-replay.c create mode 100644 replay/replay-net.c
Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
On 11/09/16 at 04:38pm, Laszlo Ersek wrote: > On 11/09/16 15:47, Daniel P. Berrange wrote: > > On Wed, Nov 09, 2016 at 01:20:51PM +0100, Andrew Jones wrote: > >> On Wed, Nov 09, 2016 at 11:58:19AM +, Daniel P. Berrange wrote: > >>> On Wed, Nov 09, 2016 at 12:48:09PM +0100, Andrew Jones wrote: > On Wed, Nov 09, 2016 at 11:37:35AM +, Daniel P. Berrange wrote: > > On Wed, Nov 09, 2016 at 12:26:17PM +0100, Laszlo Ersek wrote: > >> On 11/09/16 11:40, Andrew Jones wrote: > >>> On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote: > Hi, > > Latest linux kernel enabled kaslr to randomiz phys/virt memory > addresses, we had some effort to support kexec/kdump so that crash > utility can still works in case crashed kernel has kaslr enabled. > > But according to Dave Anderson virsh dump does not work, quoted > messages > from Dave below: > > """ > with virsh dump, there's no way of even knowing that KASLR > has randomized the kernel __START_KERNEL_map region, because there > is no > virtual address information -- e.g., like "SYMBOL(_stext)" in the > kdump > vmcoreinfo data to compare against the vmlinux file symbol value. > Unless virsh dump can export some basic virtual memory data, which > they say it can't, I don't see how KASLR can ever be supported. > """ > > I assume virsh dump is using qemu guest memory dump facility so it > should be first addressed in qemu. Thus post this query to qemu devel > list. If this is not correct please let me know. > > Could you qemu dump people make it work? Or we can not support virt > dump > as long as KASLR being enabled. Latest Fedora kernel has enabled it > in x86_64. > > >>> > >>> When the -kernel command line option is used, then it may be possible > >>> to extract some information that could be used to supplement the > >>> memory > >>> dump that dump-guest-memory provides. However, that would be a > >>> specific > >>> use. In general, QEMU knows nothing about the guest kernel. It doesn't > >>> know where it is in the disk image, and it doesn't even know if it's > >>> Linux. > >>> > >>> Is there anything a guest userspace application could probe from e.g. > >>> /proc that would work? If so, then the guest agent could gain a new > >>> feature providing that. > >> > >> I fully agree. This is exactly what I suggested too, independently, in > >> the downstream thread, before arriving at this upstream thread. Let me > >> quote that email: > >> > >> On 11/09/16 12:09, Laszlo Ersek wrote: > >>> [...] the dump-guest-memory QEMU command supports an option called > >>> "paging". Here's its documentation, from the "qapi-schema.json" source > >>> file: > >>> > # @paging: if true, do paging to get guest's memory mapping. This > allows > # using gdb to process the core file. > # > # IMPORTANT: this option can make QEMU allocate several > gigabytes > # of RAM. This can happen for a large guest, or a > # malicious guest pretending to be large. > # > # Also, paging=true has the following limitations: > # > # 1. The guest may be in a catastrophic state or can > have corrupted > #memory, which cannot be trusted > # 2. The guest can be in real-mode even if paging is > enabled. For > #example, the guest uses ACPI to sleep, and ACPI > sleep state > #goes in real-mode > # 3. Currently only supported on i386 and x86_64. > # > >>> > >>> "virsh dump --memory-only" sets paging=false, for obvious reasons. > >>> > >>> [...] the dump-guest-memory command provides a raw snapshot of the > >>> virtual machine's memory (and of the registers of the VCPUs); it is > >>> not enlightened about the guest. > >>> > >>> If the additional information you are looking for can be retrieved > >>> within the running Linux guest, using an appropriately privieleged > >>> userspace process, then I would recommend considering an extension to > >>> the qemu guest agent. The management layer (libvirt, [...]) could > >>> first invoke the guest agent (a process with root privileges running > >>> in the guest) from the host side, through virtio-serial. The new guest > >>> agent command would return the information necessary to deal with > >>> KASLR. Then the management layer would initiate the dump like always. > >>> Finally, the extra in
Re: [Qemu-devel] [PULL V2 0/3] Net patches
Hi~ Jason~ Can you pick up this patch? [PATCH] docs: fix COLO architecture diagram Thanks Zhang Chen On 11/14/2016 10:54 AM, Jason Wang wrote: The following changes since commit 83c83f9a5266ff113060f887f106a47920fa6974: Merge remote-tracking branch 'bonzini/tags/for-upstream' into staging (2016-11-11 12:51:50 +) are available in the git repository at: https://github.com/jasowang/qemu.git tags/net-pull-request for you to fetch changes up to 73c46860454f8e43d1679d1367552d15a66b7790: net: fix sending of data with -net socket, listen backend (2016-11-14 10:26:22 +0800) Changes from V1: - no change, V1 misses the list Daniel P. Berrange (1): net: fix sending of data with -net socket, listen backend Pavel Dovgalyuk (1): record/replay: add network support Yuri Benditovich (1): net: skip virtio-net config of deleted nic's peers docs/replay.txt | 14 +++ hw/net/virtio-net.c | 4 ++ include/sysemu/replay.h | 12 ++ net/Makefile.objs| 1 + net/filter-replay.c | 92 ++ net/net.c| 5 +-- net/socket.c | 1 + replay/Makefile.objs | 1 + replay/replay-events.c | 11 + replay/replay-internal.h | 10 + replay/replay-net.c | 102 +++ replay/replay.c | 2 +- vl.c | 3 +- 13 files changed, 253 insertions(+), 5 deletions(-) create mode 100644 net/filter-replay.c create mode 100644 replay/replay-net.c -- Thanks zhangchen
[Qemu-devel] [PATCH] crypto: add virtio-crypto driver
This patch introduces virtio-crypto driver for Linux Kernel. The virtio crypto device is a virtual cryptography device as well as a kind of virtual hardware accelerator for virtual machines. The encryption anddecryption requests are placed in the data queue and are ultimately handled by thebackend crypto accelerators. The second queue is the control queue used to create or destroy sessions for symmetric algorithms and will control some advanced features in the future. The virtio crypto device provides the following cryptoservices: CIPHER, MAC, HASH, and AEAD. For more information about virtio-crypto device, please see: http://qemu-project.org/Features/VirtioCrypto CC: Michael S. Tsirkin CC: Cornelia Huck CC: Stefan Hajnoczi CC: Herbert Xu CC: Halil Pasic CC: David S. Miller CC: Zeng Xin Signed-off-by: Gonglei --- MAINTAINERS | 8 + drivers/crypto/Kconfig | 2 + drivers/crypto/Makefile | 1 + drivers/crypto/virtio/Kconfig| 10 + drivers/crypto/virtio/Makefile | 5 + drivers/crypto/virtio/virtio_crypto.c| 437 +++ drivers/crypto/virtio/virtio_crypto_algs.c | 496 +++ drivers/crypto/virtio/virtio_crypto_common.h | 115 +++ drivers/crypto/virtio/virtio_crypto_mgr.c| 261 ++ include/uapi/linux/Kbuild| 1 + include/uapi/linux/virtio_crypto.h | 436 +++ include/uapi/linux/virtio_ids.h | 1 + 12 files changed, 1773 insertions(+) create mode 100644 drivers/crypto/virtio/Kconfig create mode 100644 drivers/crypto/virtio/Makefile create mode 100644 drivers/crypto/virtio/virtio_crypto.c create mode 100644 drivers/crypto/virtio/virtio_crypto_algs.c create mode 100644 drivers/crypto/virtio/virtio_crypto_common.h create mode 100644 drivers/crypto/virtio/virtio_crypto_mgr.c create mode 100644 include/uapi/linux/virtio_crypto.h diff --git a/MAINTAINERS b/MAINTAINERS index 411e3b8..d6b18bb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12844,6 +12844,14 @@ S: Maintained F: drivers/virtio/virtio_input.c F: include/uapi/linux/virtio_input.h +VIRTIO CRYPTO DRIVER +M: Gonglei +L: virtualizat...@lists.linux-foundation.org +L: linux-cry...@vger.kernel.org +S: Maintained +F: drivers/crypto/virtio/ +F: include/uapi/linux/virtio_crypto.h + VIA RHINE NETWORK DRIVER S: Orphan F: drivers/net/ethernet/via/via-rhine.c diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 4d2b81f..7956478 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -555,4 +555,6 @@ config CRYPTO_DEV_ROCKCHIP source "drivers/crypto/chelsio/Kconfig" +source "drivers/crypto/virtio/Kconfig" + endif # CRYPTO_HW diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index ad7250f..bc53cb8 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -32,3 +32,4 @@ obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/ obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/ obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/ obj-$(CONFIG_CRYPTO_DEV_CHELSIO) += chelsio/ +obj-$(CONFIG_CRYPTO_DEV_VIRTIO) += virtio/ diff --git a/drivers/crypto/virtio/Kconfig b/drivers/crypto/virtio/Kconfig new file mode 100644 index 000..ceae88c --- /dev/null +++ b/drivers/crypto/virtio/Kconfig @@ -0,0 +1,10 @@ +config CRYPTO_DEV_VIRTIO + tristate "VirtIO crypto driver" + depends on VIRTIO +select CRYPTO_AEAD +select CRYPTO_AUTHENC +select CRYPTO_BLKCIPHER + default m + help + This driver provides support for virtio crypto device. If you + choose 'M' here, this module will be called virtio-crypto. diff --git a/drivers/crypto/virtio/Makefile b/drivers/crypto/virtio/Makefile new file mode 100644 index 000..a316e92 --- /dev/null +++ b/drivers/crypto/virtio/Makefile @@ -0,0 +1,5 @@ +obj-$(CONFIG_CRYPTO_DEV_VIRTIO) += virtio-crypto.o +virtio-crypto-objs := \ + virtio_crypto_algs.o \ + virtio_crypto_mgr.o \ + virtio_crypto.o diff --git a/drivers/crypto/virtio/virtio_crypto.c b/drivers/crypto/virtio/virtio_crypto.c new file mode 100644 index 000..6c9de18 --- /dev/null +++ b/drivers/crypto/virtio/virtio_crypto.c @@ -0,0 +1,437 @@ + /* Driver for Virtio crypto device. + * + * Copyright 2016 HUAWEI TECHNOLOGIES CO., LTD. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU Gene
[Qemu-devel] [PATCH 2/3] ppc/pnv: fix xscom address translation for POWER9
High addresses can overflow the uint32_t pcba variable after the 8byte
shift.
Signed-off-by: Cédric Le Goater
---
hw/ppc/pnv_xscom.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
index f46646141a96..8da271872f59 100644
--- a/hw/ppc/pnv_xscom.c
+++ b/hw/ppc/pnv_xscom.c
@@ -124,8 +124,8 @@ static uint64_t xscom_read(void *opaque, hwaddr addr,
unsigned width)
goto complete;
}
-val = address_space_ldq(&chip->xscom_as, pcba << 3, MEMTXATTRS_UNSPECIFIED,
-&result);
+val = address_space_ldq(&chip->xscom_as, (uint64_t) pcba << 3,
+MEMTXATTRS_UNSPECIFIED, &result);
if (result != MEMTX_OK) {
qemu_log_mask(LOG_GUEST_ERROR, "XSCOM read failed at @0x%"
HWADDR_PRIx " pcba=0x%08x\n", addr, pcba);
@@ -150,8 +150,8 @@ static void xscom_write(void *opaque, hwaddr addr, uint64_t
val,
goto complete;
}
-address_space_stq(&chip->xscom_as, pcba << 3, val, MEMTXATTRS_UNSPECIFIED,
- &result);
+address_space_stq(&chip->xscom_as, (uint64_t) pcba << 3, val,
+ MEMTXATTRS_UNSPECIFIED, &result);
if (result != MEMTX_OK) {
qemu_log_mask(LOG_GUEST_ERROR, "XSCOM write failed at @0x%"
HWADDR_PRIx " pcba=0x%08x data=0x%" PRIx64 "\n",
--
2.7.4
[Qemu-devel] [PATCH 0/3] ppc/pnv: XSCOM fixes and unit tests
Hello, Here is a little serie adding some fixes for the XSCOM registers of the POWER9 cores and a unit test. Thanks, C. Cédric Le Goater (3): ppc/pnv: add a 'xscom_core_base' field to PnvChipClass ppc/pnv: fix xscom address translation for POWER9 tests: add XSCOM tests for the PowerNV machine hw/ppc/pnv.c | 8 ++- hw/ppc/pnv_xscom.c | 8 +-- include/hw/ppc/pnv.h | 1 + include/hw/ppc/pnv_xscom.h | 5 +- tests/Makefile.include | 1 + tests/pnv-xscom-test.c | 139 + 6 files changed, 154 insertions(+), 8 deletions(-) create mode 100644 tests/pnv-xscom-test.c -- 2.7.4
[Qemu-devel] [PATCH 1/3] ppc/pnv: add a 'xscom_core_base' field to PnvChipClass
The XSCOM addresses for the core registers are encoded in a slightly
different way on POWER8 and POWER9.
Signed-off-by: Cédric Le Goater
---
hw/ppc/pnv.c | 8 +++-
include/hw/ppc/pnv.h | 1 +
include/hw/ppc/pnv_xscom.h | 5 ++---
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 6af34241f248..e7779581545d 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -521,6 +521,7 @@ static void pnv_chip_power8e_class_init(ObjectClass *klass,
void *data)
k->cores_mask = POWER8E_CORE_MASK;
k->core_pir = pnv_chip_core_pir_p8;
k->xscom_base = 0x003fc00ull;
+k->xscom_core_base = 0x1000ull;
dc->desc = "PowerNV Chip POWER8E";
}
@@ -542,6 +543,7 @@ static void pnv_chip_power8_class_init(ObjectClass *klass,
void *data)
k->cores_mask = POWER8_CORE_MASK;
k->core_pir = pnv_chip_core_pir_p8;
k->xscom_base = 0x003fc00ull;
+k->xscom_core_base = 0x1000ull;
dc->desc = "PowerNV Chip POWER8";
}
@@ -563,6 +565,7 @@ static void pnv_chip_power8nvl_class_init(ObjectClass
*klass, void *data)
k->cores_mask = POWER8_CORE_MASK;
k->core_pir = pnv_chip_core_pir_p8;
k->xscom_base = 0x003fc00ull;
+k->xscom_core_base = 0x1000ull;
dc->desc = "PowerNV Chip POWER8NVL";
}
@@ -584,6 +587,7 @@ static void pnv_chip_power9_class_init(ObjectClass *klass,
void *data)
k->cores_mask = POWER9_CORE_MASK;
k->core_pir = pnv_chip_core_pir_p9;
k->xscom_base = 0x00603fcull;
+k->xscom_core_base = 0x0ull;
dc->desc = "PowerNV Chip POWER9";
}
@@ -691,7 +695,9 @@ static void pnv_chip_realize(DeviceState *dev, Error **errp)
object_unref(OBJECT(pnv_core));
/* Each core has an XSCOM MMIO region */
-pnv_xscom_add_subregion(chip, PNV_XSCOM_EX_CORE_BASE(core_hwid),
+pnv_xscom_add_subregion(chip,
+PNV_XSCOM_EX_CORE_BASE(pcc->xscom_core_base,
+ core_hwid),
&PNV_CORE(pnv_core)->xscom_regs);
i++;
}
diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index 7bee658733db..df98a72006e4 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -69,6 +69,7 @@ typedef struct PnvChipClass {
uint64_t cores_mask;
hwaddr xscom_base;
+hwaddr xscom_core_base;
uint32_t (*core_pir)(PnvChip *chip, uint32_t core_id);
} PnvChipClass;
diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
index 41a5127a1907..0faa1847bf13 100644
--- a/include/hw/ppc/pnv_xscom.h
+++ b/include/hw/ppc/pnv_xscom.h
@@ -40,7 +40,7 @@ typedef struct PnvXScomInterfaceClass {
} PnvXScomInterfaceClass;
/*
- * Layout of the XSCOM PCB addresses of EX core 1
+ * Layout of the XSCOM PCB addresses of EX core 1 (POWER 8)
*
* GPIO0x1100
* SCOM0x1101
@@ -54,8 +54,7 @@ typedef struct PnvXScomInterfaceClass {
* PCB SLAVE 0x110F
*/
-#define PNV_XSCOM_EX_BASE 0x1000
-#define PNV_XSCOM_EX_CORE_BASE(i) (PNV_XSCOM_EX_BASE | (((uint64_t)i) << 24))
+#define PNV_XSCOM_EX_CORE_BASE(base, i) (base | (((uint64_t)i) << 24))
#define PNV_XSCOM_EX_CORE_SIZE0x10
#define PNV_XSCOM_LPC_BASE0xb0020
--
2.7.4
[Qemu-devel] [PATCH 3/3] tests: add XSCOM tests for the PowerNV machine
Add a couple of tests on the XSCOM bus of the PowerNV machine for the
the POWER8 and POWER9 CPUs. The first tests reads the CFAM identifier
of the chip. The second test goes further in the XSCOM address space
and reaches the cores to read their DTS registers.
Signed-off-by: Cédric Le Goater
---
tests/Makefile.include | 1 +
tests/pnv-xscom-test.c | 139 +
2 files changed, 140 insertions(+)
create mode 100644 tests/pnv-xscom-test.c
diff --git a/tests/Makefile.include b/tests/Makefile.include
index de516341fd44..90c9ad9ac6e1 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -270,6 +270,7 @@ gcov-files-ppc64-y = ppc64-softmmu/hw/ppc/spapr_pci.c
check-qtest-ppc64-y += tests/endianness-test$(EXESUF)
check-qtest-ppc64-y += tests/boot-order-test$(EXESUF)
check-qtest-ppc64-y += tests/prom-env-test$(EXESUF)
+check-qtest-ppc64-y += tests/pnv-xscom-test$(EXESUF)
check-qtest-ppc64-y += tests/drive_del-test$(EXESUF)
check-qtest-ppc64-y += tests/postcopy-test$(EXESUF)
check-qtest-ppc64-y += tests/boot-serial-test$(EXESUF)
diff --git a/tests/pnv-xscom-test.c b/tests/pnv-xscom-test.c
new file mode 100644
index ..8c16e32e8b4e
--- /dev/null
+++ b/tests/pnv-xscom-test.c
@@ -0,0 +1,139 @@
+/*
+ * QTest testcase for PowerNV XSCOM bus
+ *
+ * Copyright (c) 2016, IBM Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later. See the COPYING file in the top-level directory.
+ */
+#include "qemu/osdep.h"
+
+#include "libqtest.h"
+
+typedef enum PnvChipType {
+PNV_CHIP_POWER8E, /* AKA Murano (default) */
+PNV_CHIP_POWER8, /* AKA Venice */
+PNV_CHIP_POWER8NVL, /* AKA Naples */
+PNV_CHIP_POWER9, /* AKA Nimbus */
+} PnvChipType;
+
+typedef struct PnvChip {
+PnvChipType chip_type;
+const char *cpu_model;
+uint64_txscom_base;
+uint64_txscom_core_base;
+uint64_tcfam_id;
+uint32_tfirst_core;
+} PnvChip;
+
+static const PnvChip pnv_chips[] = {
+{
+.chip_type = PNV_CHIP_POWER8,
+.cpu_model = "POWER8",
+.xscom_base = 0x0003fc00ull,
+.xscom_core_base = 0x1000ull,
+.cfam_id= 0x220ea0498000ull,
+.first_core = 0x1,
+}, {
+.chip_type = PNV_CHIP_POWER8NVL,
+.cpu_model = "POWER8NVL",
+.xscom_base = 0x0003fc00ull,
+.xscom_core_base = 0x1000ull,
+.cfam_id= 0x120d30498000ull,
+.first_core = 0x1,
+}, {
+.chip_type = PNV_CHIP_POWER9,
+.cpu_model = "POWER9",
+.xscom_base = 0x000603fcull,
+.xscom_core_base = 0x0ull,
+.cfam_id= 0x100d10498000ull,
+.first_core = 0x20,
+},
+};
+
+static uint64_t pnv_xscom_addr(const PnvChip *chip, uint32_t pcba)
+{
+uint64_t addr = chip->xscom_base;
+
+if (chip->chip_type == PNV_CHIP_POWER9) {
+return addr | ((uint64_t) pcba << 3);
+} else {
+return addr | (((uint64_t) pcba << 4) & ~0xfful) |
+(((uint64_t) pcba << 3) & 0x78);
+}
+}
+
+static uint64_t pnv_xscom_read(const PnvChip *chip, uint32_t pcba)
+{
+return readq(pnv_xscom_addr(chip, pcba));
+}
+
+static void test_xscom_cfam_id(const PnvChip *chip)
+{
+uint64_t f000f = pnv_xscom_read(chip, 0xf000f);
+
+g_assert_cmphex(f000f, ==, chip->cfam_id);
+}
+
+static void test_cfam_id(const void *data)
+{
+char *args;
+const PnvChip *chip = data;
+
+args = g_strdup_printf("-M powernv,accel=tcg -cpu %s", chip->cpu_model);
+
+qtest_start(args);
+test_xscom_cfam_id(chip);
+qtest_quit(global_qtest);
+
+g_free(args);
+}
+
+#define PNV_XSCOM_EX_CORE_BASE(chip, i) \
+((chip)->xscom_core_base | (((uint64_t)i) << 24))
+#define PNV_XSCOM_EX_DTS_RESULT0 0x5
+
+static void test_xscom_core(const PnvChip *chip)
+{
+uint32_t first_core_dts0 =
+PNV_XSCOM_EX_CORE_BASE(chip, chip->first_core) |
+PNV_XSCOM_EX_DTS_RESULT0;
+uint64_t dts0 = pnv_xscom_read(chip, first_core_dts0);
+
+g_assert_cmphex(dts0, ==, 0x26f024f023full);
+}
+
+static void test_core(const void *data)
+{
+char *args;
+const PnvChip *chip = data;
+
+args = g_strdup_printf("-M powernv,accel=tcg -cpu %s", chip->cpu_model);
+
+qtest_start(args);
+test_xscom_core(chip);
+qtest_quit(global_qtest);
+
+g_free(args);
+}
+
+static void add_test(const char *name, void (*test)(const void *data))
+{
+int i;
+
+for (i = 0; i < ARRAY_SIZE(pnv_chips); i++) {
+char *tname = g_strdup_printf("pnv-xscom/%s/%s", name,
+ pnv_chips[i].cpu_model);
+qtest_add_data_func(tname, &pnv_chips[i], test);
+g_free(tname);
+}
+}
+
+int main(int argc, char **argv)
+{
+g_test_init(&argc, &argv, NULL);
+
+add_test("cfam_id", test_cfam_id);
+add_test("core", test_core);
+return g_test_run();
+}
--
Re: [Qemu-devel] [Qemu-ppc] [RFC 16/17] ppc: Remove counter-productive "sanity checks" in migration
On Mon, Nov 14, 2016 at 01:34:55PM +1100, Alexey Kardashevskiy wrote:
> On 12/11/16 05:13, Greg Kurz wrote:
> > On Tue, 8 Nov 2016 16:31:08 +1100
> > David Gibson wrote:
> >
> >> On Fri, Nov 04, 2016 at 04:52:39PM +1100, Alexey Kardashevskiy wrote:
> >>> On 30/10/16 22:12, David Gibson wrote:
> When vmstate for the ppc cpu was introduced in a90db158 "target-ppc:
> Convert ppc cpu savevm to VMStateDescription", several "sanity check"
> fields were included, verifying that certain cpu parameters matched
> between
> source and destination.
>
> This turns out not to have been a good idea. For one thing it's
> redundant
> with existing checks for a compatible cpu version at either end. But
> more
> importantly the insns_flags and insns_flags2 checks actively break
> things:
> they expose what's essentially an internal TCG implementation detail in
> the
> migration stream. That means that when new instruction classes are added
> or rearranged, migration can break.
>
> This removes these ill-considered sanity checks.
>
> Signed-off-by: David Gibson
> ---
> target-ppc/machine.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/target-ppc/machine.c b/target-ppc/machine.c
> index 62b9e94..453ef0a 100644
> --- a/target-ppc/machine.c
> +++ b/target-ppc/machine.c
> @@ -602,10 +602,10 @@ const VMStateDescription vmstate_ppc_cpu = {
> /* FIXME: access_type? */
>
> /* Sanity checking */
> -VMSTATE_UINTTL_EQUAL(env.msr_mask, PowerPCCPU),
> -VMSTATE_UINT64_EQUAL(env.insns_flags, PowerPCCPU),
> -VMSTATE_UINT64_EQUAL(env.insns_flags2, PowerPCCPU),
> -VMSTATE_UINT32_EQUAL(env.nb_BATs, PowerPCCPU),
> +VMSTATE_UNUSED(sizeof(target_ulong) /* msr_mask */
> + + sizeof(uint64_t) /* insns_flags */
> + + sizeof(uint64_t) /* insns_flags2 */
> + + sizeof(uint32_t)), /* nb_BATs */
> >>>
> >>>
> >>> This breaks migration to older QEMU:
> >>>
> >>> 25055@1478238734.537761:vmstate_load_field_error field "env.msr_mask" load
> >>> failed, ret = -22
> >>
> >> Again, I don't think we generally support backwards migration.
> >>
> >> That said, it would be nice here to do a "set to this field on
> >> ourgoing migration, but ignore on incoming migration". Do you know a
> >> way to do that?
> >>
> >
> > This doesn't exist in vmstate but it is certainly doable. An alternative
> > would be to always send the fields, but have the destination to use
> > pre_load and post_load callbacks to preserve its state.
>
>
> A simpler way would be:
>
> 1. add a copy for each field (s/msr_mask/mig_msr_mask/),
> 2. get rid of _EQUAL bits,
> 3. implement .pre_save callback which would initialize mig_xxx
>
> And that's it, .pre_load/.post_load is not needed.
Yeah, it works, but crufts up the runtime structures with extra fields
related only to migration with old versions. I think just dropping
the backwards migration is a better option in this case.
>
>
>
>
> >
> >> a
> >>>
> >>>
> >>>
> VMSTATE_END_OF_LIST()
> },
> .subsections = (const VMStateDescription*[]) {
>
> >>>
> >>>
> >>
> >
>
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [Qemu-devel] [PATCH 2/4] hw/misc: add a TMP42{1, 2, 3} device model
On 05/23/2016 05:53 AM, Andrew Jeffery wrote:
> Hi Cédric,
>
> On Fri, 2016-05-20 at 18:31 +0200, Cédric Le Goater wrote:
>> Largely inspired by the TMP105 temperature sensor, this patch brings
>> to Qemu a model for TMP42{1,2,3} temperature sensors.
>>
>> Specs can be found here :
>>
>> http://www.ti.com/lit/gpn/tmp421
>>
>> Signed-off-by: Cédric Le Goater
>> ---
>> hw/misc/Makefile.objs | 1 +
>> hw/misc/tmp421.c | 395
>> ++
>> 2 files changed, 396 insertions(+)
>> create mode 100644 hw/misc/tmp421.c
>>
>> diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
>> index 1faf163c59f3..e50596965b03 100644
>> --- a/hw/misc/Makefile.objs
>> +++ b/hw/misc/Makefile.objs
>> @@ -1,6 +1,7 @@
>> common-obj-$(CONFIG_APPLESMC) += applesmc.o
>> common-obj-$(CONFIG_MAX111X) += max111x.o
>> common-obj-$(CONFIG_TMP105) += tmp105.o
>> +common-obj-$(CONFIG_ASPEED_SOC) += tmp421.o
>> common-obj-$(CONFIG_ISA_DEBUG) += debugexit.o
>> common-obj-$(CONFIG_SGA) += sga.o
>> common-obj-$(CONFIG_ISA_TESTDEV) += pc-testdev.o
>> diff --git a/hw/misc/tmp421.c b/hw/misc/tmp421.c
>> new file mode 100644
>> index ..e385ce053f5e
>> --- /dev/null
>> +++ b/hw/misc/tmp421.c
>> @@ -0,0 +1,395 @@
>> +/*
>> + * Texas Instruments TMP421 temperature sensor.
>> + *
>> + * Copyright (c) 2016 IBM Corporation.
>> + *
>> + * Largely inspired by :
>> + *
>> + * Texas Instruments TMP105 temperature sensor.
>> + *
>> + * Copyright (C) 2008 Nokia Corporation
>> + * Written by Andrzej Zaborowski
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 or
>> + * (at your option) version 3 of the License.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along
>> + * with this program; if not, see
Re: [Qemu-devel] virtIO question
Hello，teacher,I may be found where the driver add mutiple buffer to virtqueue and then kick qemu side. It is when driver use NAPI to poll the device to get buffers,and it is in receive queue.but in transmit queue,every time driver add a buffer to virtqueue,then kick function is called!!!why ??is qemu handle buffer faster than driver add it?? thank you very much! zhun...@gmail.com From: Stefan Hajnoczi Date: 2016-11-11 20:03 To: zhun...@gmail.com CC: qemu Subject: Re: Re: [Qemu-devel] virtIO question On Thu, Nov 10, 2016 at 08:16:38PM +0800, zhun...@gmail.com wrote: > From this point of view ,I think it make sense well, thank you very much! > but I have another question about notify mechanism between virtIO driver and > qemu. > according the source code of Linux and qemu, > when driver add a sg buffer to send queue named sq, > sq->vq->vring.avail->idx++ > vq->num_added++ > and then use virtqueue_kick_prepare to make sure if need notify qemu. > it (new_idx-event_idx)<(new_idx-old_idx) This expression is wrong. The specification and Linux code both say: (u16)(new_idx - event_idx - 1) < (u16)(new_idx - old_idx) Both the (u16) and the -1 matter. Maybe that's why you are confused by this? > if it is true,then notify other side. > However,every time driver add a sg,then virtqueue_kick_prepare is called,and > vq->num_added is reseted to 0,so in fact ,I think vq->num_added is always 0 > or 1。 A driver may add multiple buffers to the virtqueue by calling virtqueue_add_sgs() or similar functions multiple times before kicking. Therefore vq->num_added > 1 is possible. > as to qemu side,every time when pop a elem from virtqueue,it set > VRingUsed.ring[vring.num] to the lastest VRingAvail.idx, this according the > arithmetic ((new_idx-event_idx)<(new_idx-old_idx)),it seems that this > mechanism does not make sense You are basically asking "how does event_idx work?". The specification says: "The driver can ask the device to delay interrupts until an entry with an index specified by the “used_event” field is written in the used ring (equivalently, until the idx field in the used ring will reach the value used_event + 1)." and: "The device can ask the driver to delay notifications until an entry with an index specified by the “avail_event” field is written in the available ring (equivalently, until the idx field in the used ring will reach the value avail_event + 1)." Whenever the device or driver wants to notify, it first checks if the index update crossed the event index set by the other side.
[Qemu-devel] [PATCH v7 06/10] megasas: remove unnecessary megasas_use_msix()
Also move certain hunk above, to place msix init related code together.
CC: Hannes Reinecke
CC: Paolo Bonzini
CC: Markus Armbruster
CC: Marcel Apfelbaum
CC: Michael S. Tsirkin
Reviewed-by: Markus Armbruster
Reviewed-by: Hannes Reinecke
Signed-off-by: Cao jin
---
hw/scsi/megasas.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index 6cef9a3..ba79e7a 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -155,11 +155,6 @@ static bool megasas_use_queue64(MegasasState *s)
return s->flags & MEGASAS_MASK_USE_QUEUE64;
}
-static bool megasas_use_msix(MegasasState *s)
-{
-return s->msix != ON_OFF_AUTO_OFF;
-}
-
static bool megasas_is_jbod(MegasasState *s)
{
return s->flags & MEGASAS_MASK_USE_JBOD;
@@ -2299,9 +2294,7 @@ static void megasas_scsi_uninit(PCIDevice *d)
{
MegasasState *s = MEGASAS(d);
-if (megasas_use_msix(s)) {
-msix_uninit(d, &s->mmio_io, &s->mmio_io);
-}
+msix_uninit(d, &s->mmio_io, &s->mmio_io);
msi_uninit(d);
}
@@ -2353,7 +2346,7 @@ static void megasas_scsi_realize(PCIDevice *dev, Error
**errp)
memory_region_init_io(&s->mmio_io, OBJECT(s), &megasas_mmio_ops, s,
"megasas-mmio", 0x4000);
-if (megasas_use_msix(s)) {
+if (s->msix != ON_OFF_AUTO_OFF) {
ret = msix_init(dev, 15, &s->mmio_io, b->mmio_bar, 0x2000,
&s->mmio_io, b->mmio_bar, 0x3800, 0x68, &err);
/* Any error other than -ENOTSUP(board's MSI support is broken)
@@ -2373,6 +2366,10 @@ static void megasas_scsi_realize(PCIDevice *dev, Error
**errp)
error_free(err);
}
+if (msix_enabled(dev)) {
+msix_vector_use(dev, 0);
+}
+
memory_region_init_io(&s->port_io, OBJECT(s), &megasas_port_ops, s,
"megasas-io", 256);
memory_region_init_io(&s->queue_io, OBJECT(s), &megasas_queue_ops, s,
@@ -2388,10 +2385,6 @@ static void megasas_scsi_realize(PCIDevice *dev, Error
**errp)
pci_register_bar(dev, b->mmio_bar, bar_type, &s->mmio_io);
pci_register_bar(dev, 3, bar_type, &s->queue_io);
-if (megasas_use_msix(s)) {
-msix_vector_use(dev, 0);
-}
-
s->fw_state = MFI_FWSTATE_READY;
if (!s->sas_addr) {
s->sas_addr = ((NAA_LOCALLY_ASSIGNED_ID << 24) |
--
2.1.0
[Qemu-devel] [PATCH v7 10/10] msi_init: convert assert to return -errno
According to the disscussion:
http://lists.nongnu.org/archive/html/qemu-devel/2016-09/msg08215.html
Let leaf function returns reasonable -errno, let caller decide how to
handle the return value.
Suggested-by: Markus Armbruster
CC: Markus Armbruster
CC: Michael S. Tsirkin
CC: Marcel Apfelbaum
Reviewed-by: Markus Armbruster
Reviewed-by: Marcel Apfelbaum
Signed-off-by: Cao jin
---
hw/pci/msi.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/pci/msi.c b/hw/pci/msi.c
index a87b227..af3efbe 100644
--- a/hw/pci/msi.c
+++ b/hw/pci/msi.c
@@ -201,9 +201,12 @@ int msi_init(struct PCIDevice *dev, uint8_t offset,
" 64bit %d mask %d\n",
offset, nr_vectors, msi64bit, msi_per_vector_mask);
-assert(!(nr_vectors & (nr_vectors - 1))); /* power of 2 */
-assert(nr_vectors > 0);
-assert(nr_vectors <= PCI_MSI_VECTORS_MAX);
+/* vector sanity test: should in range 1 - 32, should be power of 2 */
+if (!is_power_of_2(nr_vectors) || nr_vectors > PCI_MSI_VECTORS_MAX) {
+error_setg(errp, "Invalid vector number: %d", nr_vectors);
+return -EINVAL;
+}
+
/* the nr of MSI vectors is up to 32 */
vectors_order = ctz32(nr_vectors);
--
2.1.0
[Qemu-devel] [PATCH v7 02/10] hcd-xhci: check & correct param before using it
usb_xhci_realize() corrects invalid values of property "intrs"
automatically, but the uncorrected value is passed to msi_init(),
which chokes on invalid values. Delay that until after the
correction.
Resources allocated by usb_xhci_init() are leaked when msi_init()
fails. Fix by calling it after msi_init().
CC: Gerd Hoffmann
CC: Markus Armbruster
CC: Marcel Apfelbaum
CC: Michael S. Tsirkin
Signed-off-by: Cao jin
---
In previous rounds, usb_xhci_init() is moved too far from its original place,
which results the segfault(XHCIState->numports is initialized in this func),
now move it adjacent to msi_init code hunk.
hw/usb/hcd-xhci.c | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index 4acf0c6..0ace273 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -3627,25 +3627,6 @@ static void usb_xhci_realize(struct PCIDevice *dev,
Error **errp)
dev->config[PCI_CACHE_LINE_SIZE] = 0x10;
dev->config[0x60] = 0x30; /* release number */
-usb_xhci_init(xhci);
-
-if (xhci->msi != ON_OFF_AUTO_OFF) {
-ret = msi_init(dev, 0x70, xhci->numintrs, true, false, &err);
-/* Any error other than -ENOTSUP(board's MSI support is broken)
- * is a programming error */
-assert(!ret || ret == -ENOTSUP);
-if (ret && xhci->msi == ON_OFF_AUTO_ON) {
-/* Can't satisfy user's explicit msi=on request, fail */
-error_append_hint(&err, "You have to use msi=auto (default) or "
-"msi=off with this machine type.\n");
-error_propagate(errp, err);
-return;
-}
-assert(!err || xhci->msi == ON_OFF_AUTO_AUTO);
-/* With msi=auto, we fall back to MSI off silently */
-error_free(err);
-}
-
if (xhci->numintrs > MAXINTRS) {
xhci->numintrs = MAXINTRS;
}
@@ -3667,6 +3648,24 @@ static void usb_xhci_realize(struct PCIDevice *dev,
Error **errp)
xhci->max_pstreams_mask = 0;
}
+if (xhci->msi != ON_OFF_AUTO_OFF) {
+ret = msi_init(dev, 0x70, xhci->numintrs, true, false, &err);
+/* Any error other than -ENOTSUP(board's MSI support is broken)
+ * is a programming error */
+assert(!ret || ret == -ENOTSUP);
+if (ret && xhci->msi == ON_OFF_AUTO_ON) {
+/* Can't satisfy user's explicit msi=on request, fail */
+error_append_hint(&err, "You have to use msi=auto (default) or "
+"msi=off with this machine type.\n");
+error_propagate(errp, err);
+return;
+}
+assert(!err || xhci->msi == ON_OFF_AUTO_AUTO);
+/* With msi=auto, we fall back to MSI off silently */
+error_free(err);
+}
+
+usb_xhci_init(xhci);
xhci->mfwrap_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, xhci_mfwrap_timer,
xhci);
memory_region_init(&xhci->mem, OBJECT(xhci), "xhci", LEN_REGS);
--
2.1.0
[Qemu-devel] [PATCH v7 01/10] msix: Follow CODING_STYLE
CC: Markus Armbruster
CC: Marcel Apfelbaum
CC: Michael S. Tsirkin
Reviewed-by: Markus Armbruster
Signed-off-by: Cao jin
---
hw/pci/msix.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/hw/pci/msix.c b/hw/pci/msix.c
index 0ec1cb1..0cee631 100644
--- a/hw/pci/msix.c
+++ b/hw/pci/msix.c
@@ -447,8 +447,10 @@ void msix_notify(PCIDevice *dev, unsigned vector)
{
MSIMessage msg;
-if (vector >= dev->msix_entries_nr || !dev->msix_entry_used[vector])
+if (vector >= dev->msix_entries_nr || !dev->msix_entry_used[vector]) {
return;
+}
+
if (msix_is_masked(dev, vector)) {
msix_set_pending(dev, vector);
return;
@@ -483,8 +485,10 @@ void msix_reset(PCIDevice *dev)
/* Mark vector as used. */
int msix_vector_use(PCIDevice *dev, unsigned vector)
{
-if (vector >= dev->msix_entries_nr)
+if (vector >= dev->msix_entries_nr) {
return -EINVAL;
+}
+
dev->msix_entry_used[vector]++;
return 0;
}
--
2.1.0
[Qemu-devel] [PATCH v7 08/10] vmxnet3: fix reference leak issue
On migration target, msix_vector_use() will be called in vmxnet3_post_load()
in second time, without a matching second call to msi_vector_unuse(),
which results in vector reference leak.
CC: Dmitry Fleytman
CC: Jason Wang
CC: Markus Armbruster
CC: Michael S. Tsirkin
Reviewed-by: Markus Armbruster
Reviewed-by: Dmitry Fleytman
Signed-off-by: Cao jin
---
hw/net/vmxnet3.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index a433cc0..45e125e 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -2552,21 +2552,11 @@ static void vmxnet3_put_rxq_descr(QEMUFile *f, void
*pv, size_t size)
static int vmxnet3_post_load(void *opaque, int version_id)
{
VMXNET3State *s = opaque;
-PCIDevice *d = PCI_DEVICE(s);
net_tx_pkt_init(&s->tx_pkt, PCI_DEVICE(s),
s->max_tx_frags, s->peer_has_vhdr);
net_rx_pkt_init(&s->rx_pkt, s->peer_has_vhdr);
-if (s->msix_used) {
-if (!vmxnet3_use_msix_vectors(s, VMXNET3_MAX_INTRS)) {
-VMW_WRPRN("Failed to re-use MSI-X vectors");
-msix_uninit(d, &s->msix_bar, &s->msix_bar);
-s->msix_used = false;
-return -1;
-}
-}
-
vmxnet3_validate_queues(s);
vmxnet3_validate_interrupts(s);
--
2.1.0
[Qemu-devel] [PATCH v7 07/10] megasas: undo the overwrites of msi user configuration
Commit afea4e14 seems forgetting to undo the overwrites, which is
unsuitable.
CC: Hannes Reinecke
CC: Paolo Bonzini
CC: Markus Armbruster
CC: Marcel Apfelbaum
CC: Michael S. Tsirkin
Reviewed-by: Markus Armbruster
Reviewed-by: Hannes Reinecke
Signed-off-by: Cao jin
---
hw/scsi/megasas.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index ba79e7a..bbef9e9 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -2337,11 +2337,10 @@ static void megasas_scsi_realize(PCIDevice *dev, Error
**errp)
"msi=off with this machine type.\n");
error_propagate(errp, err);
return;
-} else if (ret) {
-/* With msi=auto, we fall back to MSI off silently */
-s->msi = ON_OFF_AUTO_OFF;
-error_free(err);
}
+assert(!err || s->msix == ON_OFF_AUTO_AUTO);
+/* With msi=auto, we fall back to MSI off silently */
+error_free(err);
}
memory_region_init_io(&s->mmio_io, OBJECT(s), &megasas_mmio_ops, s,
--
2.1.0
[Qemu-devel] [PATCH v7 00/10] Convert msix_init() to error
v7 changelog: 1. fix the segfaut bug in patch 2. So drop the all the R-b of it, please take a look, there is detailed description in the patch. 2. add the R-b from Hannes Reinecke Test: 1. make check: pass 2. After applied all the patch, command line test for all the affected devices, just make sure device realize process is ok, no crash, but no further use of device. CC: Jiri Pirko CC: Gerd Hoffmann CC: Dmitry Fleytman CC: Jason Wang CC: Michael S. Tsirkin CC: Hannes Reinecke CC: Paolo Bonzini CC: Alex Williamson CC: Markus Armbruster CC: Marcel Apfelbaum Cao jin (10): msix: Follow CODING_STYLE hcd-xhci: check & correct param before using it pci: Convert msix_init() to Error and fix callers to check it megasas: change behaviour of msix switch hcd-xhci: change behaviour of msix switch megasas: remove unnecessary megasas_use_msix() megasas: undo the overwrites of msi user configuration vmxnet3: fix reference leak issue vmxnet3: remove unnecessary internal msix flag msi_init: convert assert to return -errno hw/block/nvme.c| 5 +++- hw/misc/ivshmem.c | 8 +++--- hw/net/e1000e.c| 6 - hw/net/rocker/rocker.c | 7 - hw/net/vmxnet3.c | 46 +++-- hw/pci/msi.c | 9 --- hw/pci/msix.c | 42 +- hw/scsi/megasas.c | 49 --- hw/usb/hcd-xhci.c | 69 ++ hw/vfio/pci.c | 8 -- hw/virtio/virtio-pci.c | 11 include/hw/pci/msix.h | 5 ++-- 12 files changed, 164 insertions(+), 101 deletions(-) -- 2.1.0
[Qemu-devel] [PATCH v7 05/10] hcd-xhci: change behaviour of msix switch
Resolve the TODO, msix=auto means msix on; if user specify msix=on,
then device creation fail on msix_init failure.
CC: Gerd Hoffmann
CC: Michael S. Tsirkin
CC: Markus Armbruster
CC: Marcel Apfelbaum
Reviewed-by: Gerd Hoffmann
Reviewed-by: Markus Armbruster
Signed-off-by: Cao jin
---
hw/usb/hcd-xhci.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index 153b006..aaca57c 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -3636,12 +3636,14 @@ static void usb_xhci_realize(struct PCIDevice *dev,
Error **errp)
if (xhci->numintrs < 1) {
xhci->numintrs = 1;
}
+
if (xhci->numslots > MAXSLOTS) {
xhci->numslots = MAXSLOTS;
}
if (xhci->numslots < 1) {
xhci->numslots = 1;
}
+
if (xhci_get_flag(xhci, XHCI_FLAG_ENABLE_STREAMS)) {
xhci->max_pstreams_mask = 7; /* == 256 primary streams */
} else {
@@ -3669,6 +3671,28 @@ static void usb_xhci_realize(struct PCIDevice *dev,
Error **errp)
xhci->mfwrap_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, xhci_mfwrap_timer,
xhci);
memory_region_init(&xhci->mem, OBJECT(xhci), "xhci", LEN_REGS);
+if (xhci->msix != ON_OFF_AUTO_OFF) {
+ret = msix_init(dev, xhci->numintrs,
+&xhci->mem, 0, OFF_MSIX_TABLE,
+&xhci->mem, 0, OFF_MSIX_PBA,
+0x90, &err);
+/* Any error other than -ENOTSUP(board's MSI support is broken)
+ * is a programming error */
+assert(!ret || ret == -ENOTSUP);
+if (ret && xhci->msix == ON_OFF_AUTO_ON) {
+/* Can't satisfy user's explicit msix=on request, fail */
+error_append_hint(&err, "You have to use msix=auto (default) or "
+"msix=off with this machine type.\n");
+/* No instance_finalize method, need to free the resource here */
+object_unref(OBJECT(&xhci->mem));
+error_propagate(errp, err);
+return;
+}
+assert(!err || xhci->msix == ON_OFF_AUTO_AUTO);
+/* With msix=auto, we fall back to MSI off silently */
+error_free(err);
+}
+
memory_region_init_io(&xhci->mem_cap, OBJECT(xhci), &xhci_cap_ops, xhci,
"capabilities", LEN_CAP);
memory_region_init_io(&xhci->mem_oper, OBJECT(xhci), &xhci_oper_ops, xhci,
@@ -3701,17 +3725,6 @@ static void usb_xhci_realize(struct PCIDevice *dev,
Error **errp)
ret = pcie_endpoint_cap_init(dev, 0xa0);
assert(ret >= 0);
}
-
-if (xhci->msix != ON_OFF_AUTO_OFF) {
-/* TODO check for errors, and should fail when msix=on */
-ret = msix_init(dev, xhci->numintrs,
-&xhci->mem, 0, OFF_MSIX_TABLE,
-&xhci->mem, 0, OFF_MSIX_PBA,
-0x90, &err);
-if (ret) {
-error_report_err(err);
-}
-}
}
static void usb_xhci_exit(PCIDevice *dev)
--
2.1.0
[Qemu-devel] [PATCH v7 04/10] megasas: change behaviour of msix switch
Resolve the TODO, msix=auto means msix on; if user specify msix=on,
then device creation fail on msix_init failure.
Also undo the overwrites of user configuration of msix.
CC: Michael S. Tsirkin
CC: Hannes Reinecke
CC: Paolo Bonzini
CC: Markus Armbruster
CC: Marcel Apfelbaum
Reviewed-by: Markus Armbruster
Reviewed-by: Hannes Reinecke
Signed-off-by: Cao jin
---
hw/scsi/megasas.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index fada834..6cef9a3 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -2353,19 +2353,31 @@ static void megasas_scsi_realize(PCIDevice *dev, Error
**errp)
memory_region_init_io(&s->mmio_io, OBJECT(s), &megasas_mmio_ops, s,
"megasas-mmio", 0x4000);
+if (megasas_use_msix(s)) {
+ret = msix_init(dev, 15, &s->mmio_io, b->mmio_bar, 0x2000,
+&s->mmio_io, b->mmio_bar, 0x3800, 0x68, &err);
+/* Any error other than -ENOTSUP(board's MSI support is broken)
+ * is a programming error */
+assert(!ret || ret == -ENOTSUP);
+if (ret && s->msix == ON_OFF_AUTO_ON) {
+/* Can't satisfy user's explicit msix=on request, fail */
+error_append_hint(&err, "You have to use msix=auto (default) or "
+"msix=off with this machine type.\n");
+/* No instance_finalize method, need to free the resource here */
+object_unref(OBJECT(&s->mmio_io));
+error_propagate(errp, err);
+return;
+}
+assert(!err || s->msix == ON_OFF_AUTO_AUTO);
+/* With msix=auto, we fall back to MSI off silently */
+error_free(err);
+}
+
memory_region_init_io(&s->port_io, OBJECT(s), &megasas_port_ops, s,
"megasas-io", 256);
memory_region_init_io(&s->queue_io, OBJECT(s), &megasas_queue_ops, s,
"megasas-queue", 0x4);
-if (megasas_use_msix(s) &&
-msix_init(dev, 15, &s->mmio_io, b->mmio_bar, 0x2000,
- &s->mmio_io, b->mmio_bar, 0x3800, 0x68, &err)) {
-/*TODO: check msix_init's error, and should fail on msix=on */
-error_report_err(err);
-s->msix = ON_OFF_AUTO_OFF;
-}
-
if (pci_is_express(dev)) {
pcie_endpoint_cap_init(dev, 0xa0);
}
--
2.1.0
[Qemu-devel] [PATCH v7 09/10] vmxnet3: remove unnecessary internal msix flag
Internal flag msix_used is unnecessary, it has the same effect as
msix_enabled().
The corresponding msi flag is already dropped in commit 1070048e.
CC: Dmitry Fleytman
CC: Jason Wang
CC: Markus Armbruster
CC: Michael S. Tsirkin
Reviewed-by: Markus Armbruster
Reviewed-by: Dmitry Fleytman
Signed-off-by: Cao jin
---
hw/net/vmxnet3.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index 45e125e..af39965 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -281,8 +281,6 @@ typedef struct {
Vmxnet3RxqDescr rxq_descr[VMXNET3_DEVICE_MAX_RX_QUEUES];
Vmxnet3TxqDescr txq_descr[VMXNET3_DEVICE_MAX_TX_QUEUES];
-/* Whether MSI-X support was installed successfully */
-bool msix_used;
hwaddr drv_shmem;
hwaddr temp_shared_guest_driver_memory;
@@ -359,7 +357,7 @@ static bool _vmxnet3_assert_interrupt_line(VMXNET3State *s,
uint32_t int_idx)
{
PCIDevice *d = PCI_DEVICE(s);
-if (s->msix_used && msix_enabled(d)) {
+if (msix_enabled(d)) {
VMW_IRPRN("Sending MSI-X notification for vector %u", int_idx);
msix_notify(d, int_idx);
return false;
@@ -383,7 +381,7 @@ static void _vmxnet3_deassert_interrupt_line(VMXNET3State
*s, int lidx)
* This function should never be called for MSI(X) interrupts
* because deassertion never required for message interrupts
*/
-assert(!s->msix_used || !msix_enabled(d));
+assert(!msix_enabled(d));
/*
* This function should never be called for MSI(X) interrupts
* because deassertion never required for message interrupts
@@ -421,7 +419,7 @@ static void vmxnet3_trigger_interrupt(VMXNET3State *s, int
lidx)
s->interrupt_states[lidx].is_pending = true;
vmxnet3_update_interrupt_line_state(s, lidx);
-if (s->msix_used && msix_enabled(d) && s->auto_int_masking) {
+if (msix_enabled(d) && s->auto_int_masking) {
goto do_automask;
}
@@ -1428,7 +1426,7 @@ static void vmxnet3_update_features(VMXNET3State *s)
static bool vmxnet3_verify_intx(VMXNET3State *s, int intx)
{
-return s->msix_used || msi_enabled(PCI_DEVICE(s))
+return msix_enabled(PCI_DEVICE(s)) || msi_enabled(PCI_DEVICE(s))
|| intx == pci_get_byte(s->parent_obj.config + PCI_INTERRUPT_PIN) - 1;
}
@@ -1445,18 +1443,18 @@ static void vmxnet3_validate_interrupts(VMXNET3State *s)
int i;
VMW_CFPRN("Verifying event interrupt index (%d)", s->event_int_idx);
-vmxnet3_validate_interrupt_idx(s->msix_used, s->event_int_idx);
+vmxnet3_validate_interrupt_idx(msix_enabled(PCI_DEVICE(s)),
s->event_int_idx);
for (i = 0; i < s->txq_num; i++) {
int idx = s->txq_descr[i].intr_idx;
VMW_CFPRN("Verifying TX queue %d interrupt index (%d)", i, idx);
-vmxnet3_validate_interrupt_idx(s->msix_used, idx);
+vmxnet3_validate_interrupt_idx(msix_enabled(PCI_DEVICE(s)), idx);
}
for (i = 0; i < s->rxq_num; i++) {
int idx = s->rxq_descr[i].intr_idx;
VMW_CFPRN("Verifying RX queue %d interrupt index (%d)", i, idx);
-vmxnet3_validate_interrupt_idx(s->msix_used, idx);
+vmxnet3_validate_interrupt_idx(msix_enabled(PCI_DEVICE(s)), idx);
}
}
@@ -2185,6 +2183,7 @@ vmxnet3_use_msix_vectors(VMXNET3State *s, int num_vectors)
static bool
vmxnet3_init_msix(VMXNET3State *s)
{
+bool msix;
PCIDevice *d = PCI_DEVICE(s);
int res = msix_init(d, VMXNET3_MAX_INTRS,
&s->msix_bar,
@@ -2199,17 +2198,18 @@ vmxnet3_init_msix(VMXNET3State *s)
if (0 > res) {
VMW_WRPRN("Failed to initialize MSI-X, board's MSI support is broken");
-s->msix_used = false;
+msix = false;
} else {
if (!vmxnet3_use_msix_vectors(s, VMXNET3_MAX_INTRS)) {
VMW_WRPRN("Failed to use MSI-X vectors, error %d", res);
msix_uninit(d, &s->msix_bar, &s->msix_bar);
-s->msix_used = false;
+msix = false;
} else {
-s->msix_used = true;
+msix = true;
}
}
-return s->msix_used;
+
+return msix;
}
static void
@@ -2217,7 +2217,7 @@ vmxnet3_cleanup_msix(VMXNET3State *s)
{
PCIDevice *d = PCI_DEVICE(s);
-if (s->msix_used) {
+if (msix_enabled(d)) {
vmxnet3_unuse_msix_vectors(s, VMXNET3_MAX_INTRS);
msix_uninit(d, &s->msix_bar, &s->msix_bar);
}
--
2.1.0
[Qemu-devel] [PATCH v7 03/10] pci: Convert msix_init() to Error and fix callers to check it
msix_init() reports errors with error_report(), which is wrong when
it's used in realize(). The same issue was fixed for msi_init() in
commit 1108b2f.
For some devices(like e1000e, vmxnet3) who won't fail because of
msix_init's failure, suppress the error report by passing NULL error object.
Bonus: add comment for msix_init.
CC: Jiri Pirko
CC: Gerd Hoffmann
CC: Dmitry Fleytman
CC: Jason Wang
CC: Michael S. Tsirkin
CC: Hannes Reinecke
CC: Paolo Bonzini
CC: Alex Williamson
CC: Markus Armbruster
CC: Marcel Apfelbaum
Reviewed-by: Markus Armbruster
Reviewed-by: Hannes Reinecke
Signed-off-by: Cao jin
---
hw/block/nvme.c| 5 -
hw/misc/ivshmem.c | 8
hw/net/e1000e.c| 6 +-
hw/net/rocker/rocker.c | 7 ++-
hw/net/vmxnet3.c | 8 ++--
hw/pci/msix.c | 34 +-
hw/scsi/megasas.c | 5 -
hw/usb/hcd-xhci.c | 13 -
hw/vfio/pci.c | 8 ++--
hw/virtio/virtio-pci.c | 11 +--
include/hw/pci/msix.h | 5 +++--
11 files changed, 80 insertions(+), 30 deletions(-)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index d479fd2..2d703c8 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -831,6 +831,7 @@ static int nvme_init(PCIDevice *pci_dev)
{
NvmeCtrl *n = NVME(pci_dev);
NvmeIdCtrl *id = &n->id_ctrl;
+Error *err = NULL;
int i;
int64_t bs_size;
@@ -872,7 +873,9 @@ static int nvme_init(PCIDevice *pci_dev)
pci_register_bar(&n->parent_obj, 0,
PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_64,
&n->iomem);
-msix_init_exclusive_bar(&n->parent_obj, n->num_queues, 4);
+if (msix_init_exclusive_bar(&n->parent_obj, n->num_queues, 4, &err)) {
+error_report_err(err);
+}
id->vid = cpu_to_le16(pci_get_word(pci_conf + PCI_VENDOR_ID));
id->ssvid = cpu_to_le16(pci_get_word(pci_conf + PCI_SUBSYSTEM_VENDOR_ID));
diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 230e51b..ca6f804 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -749,13 +749,13 @@ static void ivshmem_reset(DeviceState *d)
}
}
-static int ivshmem_setup_interrupts(IVShmemState *s)
+static int ivshmem_setup_interrupts(IVShmemState *s, Error **errp)
{
/* allocate QEMU callback data for receiving interrupts */
s->msi_vectors = g_malloc0(s->vectors * sizeof(MSIVector));
if (ivshmem_has_feature(s, IVSHMEM_MSI)) {
-if (msix_init_exclusive_bar(PCI_DEVICE(s), s->vectors, 1)) {
+if (msix_init_exclusive_bar(PCI_DEVICE(s), s->vectors, 1, errp)) {
return -1;
}
@@ -897,8 +897,8 @@ static void ivshmem_common_realize(PCIDevice *dev, Error
**errp)
qemu_chr_fe_set_handlers(&s->server_chr, ivshmem_can_receive,
ivshmem_read, NULL, s, NULL, true);
-if (ivshmem_setup_interrupts(s) < 0) {
-error_setg(errp, "failed to initialize interrupts");
+if (ivshmem_setup_interrupts(s, errp) < 0) {
+error_prepend(errp, "Failed to initialize interrupts: ");
return;
}
}
diff --git a/hw/net/e1000e.c b/hw/net/e1000e.c
index 4994e1c..74cbbef 100644
--- a/hw/net/e1000e.c
+++ b/hw/net/e1000e.c
@@ -292,7 +292,11 @@ e1000e_init_msix(E1000EState *s)
E1000E_MSIX_IDX, E1000E_MSIX_TABLE,
&s->msix,
E1000E_MSIX_IDX, E1000E_MSIX_PBA,
-0xA0);
+0xA0, NULL);
+
+/* Any error other than -ENOTSUP(board's MSI support is broken)
+ * is a programming error. Fall back to INTx silently on -ENOTSUP */
+assert(!res || res == -ENOTSUP);
if (res < 0) {
trace_e1000e_msix_init_fail(res);
diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c
index e9d215a..8f829f2 100644
--- a/hw/net/rocker/rocker.c
+++ b/hw/net/rocker/rocker.c
@@ -1256,14 +1256,19 @@ static int rocker_msix_init(Rocker *r)
{
PCIDevice *dev = PCI_DEVICE(r);
int err;
+Error *local_err = NULL;
err = msix_init(dev, ROCKER_MSIX_VEC_COUNT(r->fp_ports),
&r->msix_bar,
ROCKER_PCI_MSIX_BAR_IDX, ROCKER_PCI_MSIX_TABLE_OFFSET,
&r->msix_bar,
ROCKER_PCI_MSIX_BAR_IDX, ROCKER_PCI_MSIX_PBA_OFFSET,
-0);
+0, &local_err);
+/* Any error other than -ENOTSUP(board's MSI support is broken)
+ * is a programming error. */
+assert(!err || err == -ENOTSUP);
if (err) {
+error_report_err(local_err);
return err;
}
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index 92f6af9..a433cc0 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -2191,10 +2191,14 @@ vmxnet3_init_msix(VMXNET3State *s)
VMXNET3_MSIX_BAR_IDX, VMXNET3_OFF_MSIX_TABLE,
&s->msix_bar,
VMXNET3_MS
Re: [Qemu-devel] [PATCH 0/4] make SMBUS/SATA/PIT configurable and introduce
On Thu, 2016-11-10 at 16:50 +0200, Michael S. Tsirkin wrote: > On Sat, Nov 05, 2016 at 03:19:47AM -0400, Chao Peng wrote: > > > > This patchset makes SMBUS/SATA/PIT configurable and introduces a > > new > > machine type q35-lite with these features disabled by default. This > > is > > useful for creating light weight virtual machine without boot time > > penalty when these devices are unused. > > > > See https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg00422. > > html > > for the background. > > Reviewed-by: Michael S. Tsirkin > > As we are in freeze now, please remember to re-test and ping after > the > release to get this applied. > Sure, I will ping you after the re-testing. Thanks, Chao > > > > > Chao Peng (4): > > pc: make smbus configurable > > pc: make sata configurable > > pc: make pit configurable > > q35: introduce q35-lite > > > > hw/i386/pc.c | 68 > > +++- > > hw/i386/pc_piix.c| 2 +- > > hw/i386/pc_q35.c | 57 ++ > > - > > include/hw/i386/pc.h | 8 +++ > > 4 files changed, 112 insertions(+), 23 deletions(-) > > > > -- > > 1.8.3.1 >
Re: [Qemu-devel] [PATCH v11 11/22] vfio iommu: Add blocking notifier to notify DMA_UNMAP
On 11/9/2016 2:58 AM, Alex Williamson wrote:
> On Wed, 9 Nov 2016 01:29:19 +0530
> Kirti Wankhede wrote:
>
>> On 11/8/2016 11:16 PM, Alex Williamson wrote:
>>> On Tue, 8 Nov 2016 21:56:29 +0530
>>> Kirti Wankhede wrote:
>>>
On 11/8/2016 5:15 AM, Alex Williamson wrote:
> On Sat, 5 Nov 2016 02:40:45 +0530
> Kirti Wankhede wrote:
>
...
>>
>> +int vfio_register_notifier(struct device *dev, struct notifier_block
>> *nb)
>
> Is the expectation here that this is a generic notifier for all
> vfio->mdev signaling? That should probably be made clear in the mdev
> API to avoid vendor drivers assuming their notifier callback only
> occurs for unmaps, even if that's currently the case.
>
Ok. Adding comment about notifier callback in mdev_device which is part
of next patch.
...
>> mutex_lock(&iommu->lock);
>>
>> -if (!iommu->external_domain) {
>> +/* Fail if notifier list is empty */
>> +if ((!iommu->external_domain) || (!iommu->notifier.head)) {
>> ret = -EINVAL;
>> goto pin_done;
>> }
>> @@ -867,6 +870,11 @@ unlock:
>> /* Report how much was unmapped */
>> unmap->size = unmapped;
>>
>> +if (unmapped && iommu->external_domain)
>> +blocking_notifier_call_chain(&iommu->notifier,
>> +
>> VFIO_IOMMU_NOTIFY_DMA_UNMAP,
>> + unmap);
>
> This is after the fact, there's already a gap here where pages are
> unpinned and the mdev device is still running.
Oh, there is a bug here, now unpin_pages() take user_pfn as argument and
find vfio_dma. If its not found, it doesn't unpin pages. We have to call
this notifier before vfio_remove_dma(). But if we call this before
vfio_remove_dma() there will be deadlock since iommu->lock is already
held here and vfio_iommu_type1_unpin_pages() will also try to hold
iommu->lock.
If we want to call blocking_notifier_call_chain() before
vfio_remove_dma(), sequence should be:
unmapped += dma->size;
mutex_unlock(&iommu->lock);
if (iommu->external_domain)) {
struct vfio_iommu_type1_dma_unmap nb_unmap;
nb_unmap.iova = dma->iova;
nb_unmap.size = dma->size;
blocking_notifier_call_chain(&iommu->notifier,
VFIO_IOMMU_NOTIFY_DMA_UNMAP,
&nb_unmap);
}
mutex_lock(&iommu->lock);
vfio_remove_dma(iommu, dma);
>>>
>>> It seems like it would be worthwhile to have the rb-tree rooted in the
>>> vfio-dma, then we only need to call the notifier if there are pages
>>> pinned within that vfio-dma (ie. the rb-tree is not empty). We can
>>> then release the lock call the notifier, re-acquire the lock, and
>>> BUG_ON if the rb-tree still is not empty. We might get duplicate pfns
>>> between separate vfio_dma structs, but as I mentioned in other replies,
>>> that seems like an exception that we don't need to optimize for.
>>>
>>
>> If we don't optimize for the case where iova from different vfio_dma are
>> mapped to same pfn and we would not consider this case for page
>> accounting then:
>
> Just to clarify, the current code (not handling mdevs) will pin and do
> page accounting per iova, regardless of whether the iova translates to a
> unique pfn. As long as we do no worse than that, I'm ok.
>
>> - have rb tree of pinned iova, where key would be iova, in each vfio_dma
>> structure.
>> - iova tracking structure would have iova and ref_count only.
>> - page accounting would only count number of iova's in rb_tree, case
>> where different iova could map to same pfn would not be considered in
>> this implementation for now.
>> - vfio_unpin_pages() would have user_pfn and pfn as input, we would
>> validate that iova exist in rb tree and trust vendor driver that
>> corresponding pfn is correct, there is no validation of pfn. If want
>> validate pfn, call GUP, verify pfn and call put_pfn().
>> - In .release() or .detach_group() path, if there are entries in this rb
>> tree, call GUP again using that iova, get pfn and then call
>> put_pfn(pfn) for ref_count+1 times. This is because we are not keeping
>> pfn in our tracking logic.
>
> Wait a sec, if we detach a group from the container and it's not the
> last group in the container (which would trigger a release), we can't
> assume anything about which vfio_dma entries were associated with that
> device. The vendor driver, through the release of the device(s) within
> that group, needs to unpin. In a container release, we need to send a
> notifier to the vendor driver(s) to cause an unpin. This is the only
> mechanism we have to ensure that vendor drivers are not leaking
>
