On Fri, Jan 04, 2019 at 02:38:23PM +0100, Paolo Bonzini wrote:
> On 27/12/18 07:34, Yang Zhong wrote:
> > From: Paolo Bonzini
> >
> > This lets you disable SCSI altogether with "CONFIG_SCSI=n".
>
> USB_STORAGE_BOT and USB_STORAGE_UAS must also select SCSI.
>
> Paolo
Thanks for Paolo's
At 2019-01-08 00:10:29, "Cornelia Huck" wrote:
>On Mon, 7 Jan 2019 16:04:35 +
>Peter Maydell wrote:
>
>> On Mon, 7 Jan 2019 at 15:57, Cornelia Huck wrote:
>> > On Mon, 7 Jan 2019 15:54:21 +
>> > Peter Maydell wrote:
>> > > On Mon, 7 Jan 2019 at 15:48, Cornelia Huck wrote:
>> > >
On Fri, Jan 04, 2019 at 02:48:03PM +0100, Thomas Huth wrote:
> On 2018-12-27 07:34, Yang Zhong wrote:
> > From: Paolo Bonzini
> >
> > Instead of including the same list of devices for each target,
> > set CONFIG_PCI to true, and make the devices default to present
> > whenever PCI is available.
On Tue, Jan 08, 2019 at 07:14:11AM +0100, Jiri Slaby wrote:
> On 07. 01. 19, 18:29, Markus Armbruster wrote:
> >static void pci_edu_uninit(PCIDevice *pdev)
> >{
> >EduState *edu = EDU(pdev);
> >
> >qemu_mutex_lock(>thr_mutex);
> >edu->stopping = true;
> >
At 2019-01-08 00:26:58, "Yuval Shaia" wrote:
>On Thu, Jan 03, 2019 at 02:47:37PM +0100, Philippe Mathieu-Daudé wrote:
>> On 1/3/19 2:03 PM, Li Qiang wrote:
>> > Spotted by Coverity: CID 1398595
>> >
>>
>> Fixes: 2b05705dc8
>>
>> > Signed-off-by: Li Qiang
>>
>> Reviewed-by: Philippe
Hi,
> +{ "migration", "decompress-error-check", "off" },
> +{ "hda-audio", "use-timer", "false" },
> +{ "cirrus-vga", "global-vmstate", "true" },
> +{ "VGA", "global-vmstate", "true" },
> +{ "vmware-svga", "global-vmstate", "true" },
> +{ "qxl-vga", "global-vmstate",
Thank you for looking into this, perhaps I could change the patch (at
least in the C part not the python script) to something like:
-phdr.p_vaddr = cpu_to_dumpXX(s, memory_mapping->virt_addr);
+phdr.p_vaddr = cpu_to_dumpXX(s, memory_mapping->virt_addr) ?
cpu_to_dumpXX(s,
On 07. 01. 19, 18:29, Markus Armbruster wrote:
>static void pci_edu_uninit(PCIDevice *pdev)
>{
>EduState *edu = EDU(pdev);
>
>qemu_mutex_lock(>thr_mutex);
>edu->stopping = true;
>qemu_mutex_unlock(>thr_mutex);
>qemu_cond_signal(>thr_cond);
>
if multiple regions in vfio are mmaped, their corresponding ramblocks
are like below, i.e. their idstrs are "".
(qemu) info ramblock
Block Name PSize Offset UsedTotal
pc.ram 4 KiB 0x 0x2000 0x2000
4 KiB
if multiple regions in vfio are mmaped, their corresponding ramblocks
are like below, i.e. their idstrs are "".
(qemu) info ramblock
Block Name PSize Offset UsedTotal
pc.ram 4 KiB 0x 0x2000 0x2000
4 KiB
On 2018/12/27 3:08, Vivek Goyal wrote:
> On Sat, Dec 22, 2018 at 05:27:28PM +0800, jiangyiwen wrote:
>> On 2018/12/11 1:31, Dr. David Alan Gilbert (git) wrote:
>>> From: "Dr. David Alan Gilbert"
>>>
>>> Hi,
>>> This is the first RFC for the QEMU side of 'virtio-fs';
>>> a new mechanism for
Hi,
> > I suspect your series uses the options visitor only because back when
> > you started, qobject_input_visitor_new_str() didn't exist.
>
> Yes, this patch series is a bit old, and at that time this was the best
> I could do. I can look into it this (probably only on the weekend
>
On Thu, Jan 03, 2019 at 05:06:32PM +0100, Thomas Huth wrote:
> On 2018-12-27 07:34, Yang Zhong wrote:
> > From: Paolo Bonzini
> >
> > Instead of including the same list of devices for each target,
> > set CONFIG_PCI to true, and make the devices default to present
> > whenever PCI is available.
On Thu, Jan 03, 2019 at 04:47:02PM +0100, Thomas Huth wrote:
> On 2018-12-27 07:34, Yang Zhong wrote:
> > From: Paolo Bonzini
> >
> > Signed-off-by: Paolo Bonzini
> > ---
> [...]
> > diff --git a/hw/ide/Kconfig b/hw/ide/Kconfig
> > index 5ec449525f..091f3a81c9 100644
> > --- a/hw/ide/Kconfig
>
On 1/8/19 12:09 AM, Peter Maydell wrote:
>> +static int rot_cell(int cell, int n)
>> +{
>> +cell |= cell << 4;
>> +cell >>= n;
>> +return cell & 0xf;
>
> This doesn't seem to do what the RotCell pseudocode does?
> Unless I've made an error, RotCell(ABCD, 1) == BCDA,
> but
On 1/7/19 11:31 PM, Peter Maydell wrote:
>> +/* Preserve the determination between upper and lower at bit 55,
>> + * and insert pointer authentication code.
>> + */
>> +if (param.tbi) {
>> +ptr &= ~MAKE_64BIT_MASK(bot_bit, 55 - bot_bit + 1);
>> +pac &=
"Zoltán Kővágó" writes:
> On 2019-01-07 14:13, Markus Armbruster wrote:
>> "Kővágó, Zoltán" writes:
>>
>>> Audio drivers now get an Audiodev * as config paramters, instead of the
>>> global audio_option structs. There is some code in audio/audio_legacy.c
>>> that converts the old environment
On 1/5/19 2:25 AM, Peter Maydell wrote:
> On Fri, 14 Dec 2018 at 05:24, Richard Henderson
> wrote:
>>
>> The cryptographic internals are stubbed out for now,
>> but the enable and trap bits are checked.
>>
>> Signed-off-by: Richard Henderson
>>
>
>> +static void QEMU_NORETURN
On Mon, Jan 07, 2019 at 05:45:22PM -0800, si-wei liu wrote:
>
>
> On 01/07/2019 03:32 PM, Michael S. Tsirkin wrote:
> > On Mon, Jan 07, 2019 at 05:29:39PM -0500, Venu Busireddy wrote:
> > > Implement the infrastructure to support datapath switching during live
> > > migration involving SR-IOV
When the representation of fpcr was changed, the user-only
initialization was not updated to match. Oops.
Fixes: f3d3aad4a92
Fixes: https://bugs.launchpad.net/bugs/1701835
Reported-by: Bruno Haible
Signed-off-by: Richard Henderson
---
target/alpha/cpu.c | 6 +++---
1 file changed, 3
Do not double-update the PC after OPCDEC.
Fixes: https://bugs.launchpad.net/bugs/1810545
Signed-off-by: Richard Henderson
---
pc-bios/palcode-clipper | Bin 152680 -> 155968 bytes
roms/qemu-palcode | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Peter Maydell
The typhoon MemoryRegionOps callbacks directly call
cpu_unassigned_access(), presumably as the old-fashioned way
to provoke a CPU exception. This won't work since commit
6ad4d7eed05a1e235 when we switched Alpha over to the
transaction_failed hook API, because now
One quite old queued patch, and two recent bug fixes.
r~
The following changes since commit c102d9471f8f02d9fbea72ec4505d7089173f470:
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190107'
into staging (2019-01-07 16:56:33 +)
are available in the Git repository
On 01/07/2019 03:32 PM, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 05:29:39PM -0500, Venu Busireddy wrote:
Implement the infrastructure to support datapath switching during live
migration involving SR-IOV devices.
1. This patch is based off on the current VIRTIO_NET_F_STANDBY feature
On 01/07/2019 03:41 PM, Alex Williamson wrote:
On Mon, 7 Jan 2019 18:22:20 -0500
"Michael S. Tsirkin" wrote:
On Mon, Jan 07, 2019 at 04:17:17PM -0700, Alex Williamson wrote:
On Mon, 7 Jan 2019 17:29:43 -0500
Venu Busireddy wrote:
From: Si-Wei Liu
When a VF is hotplugged into the
Hi Stefano,
On 1/5/19 00:41, Stefano Garzarella wrote:
+# Remove everything except the macros from bootparam.h avoiding the
+# unnecessary import of several video/ist/etc headers
+sed -e '/__ASSEMBLY__/,/__ASSEMBLY__/d' $tmpdir/include/asm/bootparam.h
>
On 1/7/19 18:33, Stefano Garzarella wrote:
On Mon, Dec 24, 2018 at 3:16 AM Li Zhijian wrote:
On 12/22/18 00:12, Michael S. Tsirkin wrote:
On Thu, Dec 06, 2018 at 10:32:11AM +0800, Li Zhijian wrote:
Don't expect read(2) can always read as many as it's told.
Signed-off-by: Li Zhijian
Pavel Tatashin wrote on Mon, Jan 07, 2019:
> I did exactly the same sequence on Kaby Lake CPU and could not
> reproduce it. What is your host CPU?
skylake consumer laptop CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
I don't have any kaby lake around; I have access to older servers though...
--
On 1/7/19 18:04, Stefano Garzarella wrote:
As Philippe already suggested,
s/espcially/especially
Hi Stefano，
thanks a lot, will update it at next version.
Thanks
I did exactly the same sequence on Kaby Lake CPU and could not
reproduce it. What is your host CPU?
Thank you,
Pasha
On Mon, Jan 7, 2019 at 6:48 PM Dominique Martinet
wrote:
>
> Pavel Tatashin wrote on Mon, Jan 07, 2019:
> > I could not reproduce the problem. Did you suspend to memory between
>
On Mon, Jan 07, 2019 at 05:24:15PM -0700, Alex Williamson wrote:
> On Mon, 7 Jan 2019 19:12:06 -0500
> "Michael S. Tsirkin" wrote:
>
> > On Mon, Jan 07, 2019 at 04:41:15PM -0700, Alex Williamson wrote:
> > > On Mon, 7 Jan 2019 18:22:20 -0500
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > On
On Mon, 7 Jan 2019 19:12:06 -0500
"Michael S. Tsirkin" wrote:
> On Mon, Jan 07, 2019 at 04:41:15PM -0700, Alex Williamson wrote:
> > On Mon, 7 Jan 2019 18:22:20 -0500
> > "Michael S. Tsirkin" wrote:
> >
> > > On Mon, Jan 07, 2019 at 04:17:17PM -0700, Alex Williamson wrote:
> > > > On Mon,
On Mon, Jan 07, 2019 at 05:30:18PM -0200, Eduardo Habkost wrote:
> The macro is only used in one place, where the purpose of the
> value is obvious. Eliminate the macro so we don't need to rely
> on stringify().
>
> Signed-off-by: Eduardo Habkost
Acked-by: David Gibson
> ---
>
On Mon, Jan 07, 2019 at 05:30:19PM -0200, Eduardo Habkost wrote:
> stringify() is useful when we need to use macros in compat_props
> (like when we set virtio-baloon-pci.class=PCI_CLASS_MEMORY_RAM at
> pc_i440fx_1_0_machine_options()), but it is pointless when we are
> already providing a number
On Mon, Jan 07, 2019 at 01:13:58PM +0100, David Hildenbrand wrote:
> On 12.12.18 10:16, David Hildenbrand wrote:
> > We better stop right away. For now, errors would be partially ignored
> > (so the guest might get informed or the device might get unplugged),
> > although actual plug/unplug will
On Mon, Jan 07, 2019 at 04:41:15PM -0700, Alex Williamson wrote:
> On Mon, 7 Jan 2019 18:22:20 -0500
> "Michael S. Tsirkin" wrote:
>
> > On Mon, Jan 07, 2019 at 04:17:17PM -0700, Alex Williamson wrote:
> > > On Mon, 7 Jan 2019 17:29:43 -0500
> > > Venu Busireddy wrote:
> > >
> > > > From:
On Mon, Jan 07, 2019 at 05:29:42PM -0500, Venu Busireddy wrote:
> Add a query command to check the status of the FAILOVER_STANDBY_CHANGED
> state of the virtio_net devices.
>
> Signed-off-by: Venu Busireddy
> ---
> hw/net/virtio-net.c| 16 +++
>
Pavel Tatashin wrote on Mon, Jan 07, 2019:
> I could not reproduce the problem. Did you suspend to memory between
> wake ups? Does this time jump happen every time, even if your laptop
> sleeps for a minute?
I'm not sure I understand "suspend to memory between the wake ups".
The full sequence is:
On 02/01/19 08:41, Li Qiang wrote:
> Commit 376692b9dc6(cpus: protect work list with work_mutex)
> initialize a work_mutex in cpu_common_initfn, however forget
> to destroy it. This will cause resource leak when hotunplug cpu
> or hotplug cpu fails.
>
> Signed-off-by: Li Qiang
> ---
> qom/cpu.c
On Mon, 7 Jan 2019 18:22:20 -0500
"Michael S. Tsirkin" wrote:
> On Mon, Jan 07, 2019 at 04:17:17PM -0700, Alex Williamson wrote:
> > On Mon, 7 Jan 2019 17:29:43 -0500
> > Venu Busireddy wrote:
> >
> > > From: Si-Wei Liu
> > >
> > > When a VF is hotplugged into the guest, datapath
On 27/12/18 21:31, Eduardo Habkost wrote:
> All that said, I miss one piece of information here: is
> XLF_CAN_BE_LOADED_ABOVE_4G really supposed to override
> header+0x22c? linux/Documentation/x86/boot.txt isn't clear about
> that. Is there any reference that can help us confirm this?
Linux has
On Mon, Jan 07, 2019 at 05:29:39PM -0500, Venu Busireddy wrote:
> Implement the infrastructure to support datapath switching during live
> migration involving SR-IOV devices.
>
> 1. This patch is based off on the current VIRTIO_NET_F_STANDBY feature
>bit and MAC address device pairing.
>
>
On Mon, 7 Jan 2019 17:29:43 -0500
Venu Busireddy wrote:
> From: Si-Wei Liu
>
> When a VF is hotplugged into the guest, datapath switching will be
> performed immediately, which is sub-optimal in terms of timing, and
> could end up with substantial network downtime. One of ways to shorten
>
On Mon, Jan 07, 2019 at 04:17:17PM -0700, Alex Williamson wrote:
> On Mon, 7 Jan 2019 17:29:43 -0500
> Venu Busireddy wrote:
>
> > From: Si-Wei Liu
> >
> > When a VF is hotplugged into the guest, datapath switching will be
> > performed immediately, which is sub-optimal in terms of timing,
On 02/01/19 15:16, Laurent Vivier wrote:
> We can have a race condition between qemu_cpu_kick_thread() and
> qemu_kvm_cpu_thread_fn() when we hotunplug a CPU. In this case,
> qemu_cpu_kick_thread() can try to kick a thread that is exiting.
> pthread_kill() returns an error and qemu is stopped by
From: Peter Maydell
The hexloader test invokes QEMU with the -nographic argument. This
is unnecessary, because the qtest_initf() function will pass it
-display none, which suffices to disable the graphical window.
It also means that the QEMU process will make the stdin/stdout
O_NONBLOCK. Since
Add a query command to check the status of the FAILOVER_STANDBY_CHANGED
state of the virtio_net devices.
Signed-off-by: Venu Busireddy
---
hw/net/virtio-net.c| 16 +++
include/hw/virtio/virtio-net.h | 1 +
include/net/net.h | 2 ++
net/net.c
gtester is deprecated by upstream glib (see for example the announcement
at https://blog.gtk.org/2018/07/11/news-from-glib-2-58/) and it does
not support tests that call g_test_skip in some glib stable releases.
glib suggests instead using Automake's TAP support, which gtest itself
supports since
From: Si-Wei Liu
Signed-off-by: Si-Wei Liu
Signed-off-by: Venu Busireddy
---
hmp.c | 5 +
hw/pci/pci.c | 5 +
qapi/misc.json | 5 -
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/hmp.c b/hmp.c
index 7828f93..7a75c93 100644
--- a/hmp.c
+++ b/hmp.c
@@
The following changes since commit 9b2e891ec5ccdb4a7d583b77988848282606fdea:
Merge remote-tracking branch 'remotes/marcel/tags/rdma-pull-request' into
staging (2018-12-22 11:25:31 +)
are available in the Git repository at:
git://github.com/bonzini/qemu.git tags/for-upstream
for you to
From: Si-Wei Liu
When a VF is hotplugged into the guest, datapath switching will be
performed immediately, which is sub-optimal in terms of timing, and
could end up with substantial network downtime. One of ways to shorten
this downtime is to switch the datapath only after the VF is seen to get
Added a new event, FAILOVER_STANDBY_CHANGED, which is emitted whenever
the status of the virtio_net driver in the guest changes (either the
guest successfully loads the driver after the F_STANDBY feature bit
is negotiated, or the guest unloads the driver or reboots). Management
stack can use this
From: Sridhar Samudrala
This feature bit can be used by a hypervisor to indicate to the virtio_net
device that it can act as a standby for another device with the same MAC
address.
Signed-off-by: Sridhar Samudrala
Signed-off-by: Venu Busireddy
---
hw/net/virtio-net.c | 2 ++
1 file changed,
Implement the infrastructure to support datapath switching during live
migration involving SR-IOV devices.
1. This patch is based off on the current VIRTIO_NET_F_STANDBY feature
bit and MAC address device pairing.
2. This set of events will be consumed by userspace management software
to
On 1/7/19 9:45 PM, Peter Maydell wrote:
> I assume 48 bits is what the kernel sets up for userspace ?
Yep. There's been some discussion about what to do with 52-bit addressing, but
it hasn't landed upstream yet.
r~
Patchew URL:
https://patchew.org/QEMU/20190107163117.16269-1-peter.mayd...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PULL 00/37] target-arm queue
Message-id:
On 1/8/19 5:00 AM, Peter Maydell wrote:
> On Mon, 7 Jan 2019 at 18:10, Peter Maydell wrote:
> (re: https://bugs.launchpad.net/bugs/1810545)
>
>> The problem seems to be that the PC we report for an OPCDEC
>> is first selected by gen_invalid()/gen_excp() in
>> target/alpha/translate.c, which uses
On Fri, 4 Jan 2019, David Gibson wrote:
On Thu, Jan 03, 2019 at 03:03:20PM +0100, BALATON Zoltan wrote:
On Wed, 2 Jan 2019, David Gibson wrote:
On Wed, Jan 02, 2019 at 03:06:38AM +0100, BALATON Zoltan wrote:
To avoid overflow if larger values are added later use ram_addr_t for
the
Patchew URL:
https://patchew.org/QEMU/1546883690-17798-1-git-send-email-venu.busire...@oracle.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v2 0/5] Support for datapath switching during live
migration
On 2019-01-07 14:13, Markus Armbruster wrote:
> "Kővágó, Zoltán" writes:
>
>> Audio drivers now get an Audiodev * as config paramters, instead of the
>> global audio_option structs. There is some code in audio/audio_legacy.c
>> that converts the old environment variables to audiodev options
On Mon, Jan 7, 2019 at 11:33 PM Eduardo Habkost wrote:
>
> Instead of verbose arrays with 4 lines for each entry, make each
> entry take only one line. This makes long arrays that couldn't
> fit in the screen become short and readable.
>
> Signed-off-by: Eduardo Habkost
> ---
>
On Mon, Jan 7, 2019 at 11:32 PM Eduardo Habkost wrote:
>
> stringify() is useful when we need to use macros in compat_props
> (like when we set virtio-baloon-pci.class=PCI_CLASS_MEMORY_RAM at
> pc_i440fx_1_0_machine_options()), but it is pointless when we are
> already providing a number literal.
On Mon, Jan 7, 2019 at 11:34 PM Eduardo Habkost wrote:
>
> The macro is only used in one place, where the purpose of the
> value is obvious. Eliminate the macro so we don't need to rely
> on stringify().
>
> Signed-off-by: Eduardo Habkost
Reviewed-by: Marc-André Lureau
> ---
>
The macro is only used in one place, where the purpose of the
value is obvious. Eliminate the macro so we don't need to rely
on stringify().
Signed-off-by: Eduardo Habkost
---
include/hw/pci-host/spapr.h | 1 -
hw/ppc/spapr.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
stringify() is useful when we need to use macros in compat_props
(like when we set virtio-baloon-pci.class=PCI_CLASS_MEMORY_RAM at
pc_i440fx_1_0_machine_options()), but it is pointless when we are
already providing a number literal.
Replace stringify() with string literals when appropriate.
Instead of verbose arrays with 4 lines for each entry, make each
entry take only one line. This makes long arrays that couldn't
fit in the screen become short and readable.
Signed-off-by: Eduardo Habkost
---
include/hw/i386/pc.h | 18 +-
hw/core/machine.c | 338
Current declarations of compat_props arrays are very verbose,
with each entry taking 4 lines of code. By omitting the field
designators, we can make each array entry fit a single line of
code and be more readable.
Eduardo Habkost (3):
spapr: Eliminate SPAPR_PCI_2_7_MMIO_WIN_SIZE macro
On Mon, Jan 07, 2019 at 09:12:06AM +0100, Cornelia Huck wrote:
> On Fri, 4 Jan 2019 20:00:50 -0200
> Eduardo Habkost wrote:
>
> > On Fri, Jan 04, 2019 at 04:13:15PM -0500, Michael S. Tsirkin wrote:
> > > On Fri, Jan 04, 2019 at 07:06:56PM -0200, Eduardo Habkost wrote:
> > > > On Fri, Jan 04,
On Thu, Dec 20, 2018 at 04:20:28PM +0100, Remy Noel wrote:
From: Remy Noel
It is possible for an io_poll/read/write callback to be concurrently executed
along
with an aio_set_fd_handlers. This can cause all sorts of problems, like
a NULL callback or a bad opaque pointer.
V2:
* Do not use
On 12/13/18 12:21 PM, Cornelia Huck wrote:
On Wed, 12 Dec 2018 09:11:13 -0500
"Jason J. Herne" wrote:
Add struct for format-0 ccws. Support executing format-0 channel
programs and waiting for their completion before continuing execution.
This will be used for real dasd ipl.
Add cu_type() to
On Mon, 7 Jan 2019 at 18:10, Peter Maydell wrote:
(re: https://bugs.launchpad.net/bugs/1810545)
> The problem seems to be that the PC we report for an OPCDEC
> is first selected by gen_invalid()/gen_excp() in
> target/alpha/translate.c, which uses pc_next (ie the insn's
> address plus 4). But
** Summary changed:
- QEMU QCow Images crow dramatically
+ QEMU QCow Images grow dramatically
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810603
Title:
QEMU QCow Images grow dramatically
The definitions in the header are not used.
Also this fixes porting SPICE to Windows where the header is not
available.
Signed-off-by: Frediano Ziglio
---
ui/spice-core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 525e0929b9..fb87944a24 100644
On 1/7/19 12:14 PM, Max Reitz wrote:
> On 07.01.19 18:59, Eric Blake wrote:
>> On 1/7/19 11:50 AM, Max Reitz wrote:
>>
>> Note I didn't set optreset. It's not present in glibc and the "hard
>> reset" is not necessary in this context.
>
> But it sure sounds like FreeBSD requires
On Mon, Jan 07, 2019 at 06:50:53PM +0100, Max Reitz wrote:
[...]
I don't particularly care how we fix this, but it breaks the nbdkit
tests on FreeBSD so I am keen to fix it one way or another.
> And if optreset not being available for glibc is the only issue, I'd say
> adding it as a weak global
If a new interrupt mode is chosen by CAS, the machine generates a
reset to reconfigure. At this point, the connection with the previous
KVM device needs to be closed and a new connection needs to opened
with the KVM device operating the chosen interrupt mode.
New routines are introduced to
This will be used to remove the MMIO regions of the POWER9 XIVE
interrupt controller when the sPAPR machine is reseted.
Signed-off-by: Cédric Le Goater
Reviewed-by: David Gibson
Signed-off-by: Cédric Le Goater
---
include/hw/sysbus.h | 1 +
hw/core/sysbus.c| 10 ++
2 files
The interrupt mode is chosen by the CAS negotiation process and
activated after a reset to take into account the required changes in
the machine. This brings new constraints on how the associated KVM IRQ
device is initialized.
Currently, each model takes care of the initialization of the KVM
The activation of the KVM IRQ device depends on the interrupt mode
chosen at CAS time by the machine and some methods used at reset or by
the migration need to be protected.
Signed-off-by: Cédric Le Goater
---
hw/intc/spapr_xive_kvm.c | 28
hw/intc/xics_kvm.c
When the VM is stopped, the VM state handler stabilizes the XIVE IC
and marks the EQ pages dirty. These are then transferred to destination
before the transfer of the device vmstates starts.
The sPAPRXive interrupt controller model captures the XIVE internal
tables, EAT and ENDT and the XiveTCTX
This routine gathers all the KVM initialization of the XICS KVM
presenter. It will be useful when the initialization of the KVM XICS
device is moved to a global routine.
Signed-off-by: Cédric Le Goater
---
hw/intc/xics_kvm.c | 29 -
1 file changed, 20 insertions(+),
The IRQ number space of the XIVE and XICS interrupt mode are aligned
when using the dual interrupt mode for the machine. This means that
the ICS offset is set to zero in QEMU and that the KVM XICS device
should be informed of this new value. Unfortunately, there is now way
to do so and KVM still
This handler is in charge of stabilizing the flow of event notifications
in the XIVE controller before migrating a guest. This is a requirement
before transferring the guest EQ pages to a destination.
When the VM is stopped, the handler masks the sources (PQ=01) to stop
the flow of events and
When the thread interrupt management state is retrieved from the KVM
VCPU, word2 is saved under the QEMU XIVE thread context to print out
the OS CAM line under the QEMU monitor.
This breaks the migration of a TCG guest (and with KVM when
kernel_irqchip=off) because the matching algorithm of the
This extends the KVM XIVE device backend with 'synchronize_state'
methods used to retrieve the state from KVM. The HW state of the
sources, the KVM device and the thread interrupt contexts are
collected for the monitor usage and also migration.
These get operations rely on their KVM counterpart
Removing RTAS handlers will become necessary when the new pseries
machine supporting multiple interrupt mode is introduced.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/spapr.h | 4
hw/ppc/spapr_rtas.c| 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git
These changes provide the interface with the KVM device implementing
the XIVE native exploitation interrupt mode. Also used to retrieve the
state of the KVM device for the monitor usage and for migration.
Available from :
https://github.com/legoater/linux/commits/xive-5.0
Signed-off-by:
This introduces a set of helpers when KVM is in use, which create the
KVM XIVE device, initialize the interrupt sources at a KVM level and
connect the interrupt presenters to the vCPU.
They also handle the initialization of the TIMA and the source ESB
memory regions of the controller. These have
Hello,
Following the 'dual' IRQ backend, this series adds KVM support to the
XIVE interrupt mode.
The first patches introduce the XIVE KVM device, state synchronization
and migration support under KVM. The second part of the patchset
modifies the XICS and XIVE interrupt models to add KVM support
;
> Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-01-05' into
> staging (2019-01-07 11:55:52 +)
>
> are available in the Git repository at:
>
> https://git.linaro.org/people/pmaydell/qemu-arm.git
> tags/pull-tar
On Thu, Jan 3, 2019 at 6:43 PM Dominique Martinet
wrote:
>
> Pavel Tatashin wrote on Thu, Jan 03, 2019:
> > Could you please send the config file and qemu arguments that were
> > used to reproduce this problem.
>
> Running qemu by hand, nothing fancy e.g. this works:
>
> # qemu-system-x86_64 -m
On 01/07/19 13:14, Marc-André Lureau wrote:
> Hi
>
> On Tue, Dec 25, 2018 at 5:52 PM Jon Doron wrote:
>>
>> vaddr needs to be equal to the paddr since the dump file represents the
>> physical memory image.
>>
>> Without setting vaddr correctly, GDB would load all the different memory
>> regions
On 21.12.18 18:09, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> On the way of backup schemes development (and in general any complicated
> developments in Qemu block layer) it would be good to have an ability to print
> out graph of block nodes with their permissions.
Thanks, applied
On 13.12.18 11:59, Andrey Shinkevich wrote:
> In the 'Format specific information' section of the 'qemu-img info'
> command output, the supplemental information about existing QCOW2
> bitmaps will be shown, such as a bitmap name, flags and granularity:
>
> image: /vz/vmprivate/VM1/harddisk.hdd
>
On 07.01.19 18:59, Eric Blake wrote:
> On 1/7/19 11:50 AM, Max Reitz wrote:
>
> Note I didn't set optreset. It's not present in glibc and the "hard
> reset" is not necessary in this context.
But it sure sounds like FreeBSD requires you to set it, doesn't it?
>
> No. Quoting
On 2018-12-10 12:31:43 -0500, Michael S. Tsirkin wrote:
> On Mon, Dec 10, 2018 at 11:15:48AM -0500, Venu Busireddy wrote:
> > From: Si-Wei Liu
> >
> > When a VF is hotplugged into the guest, datapath switching will be
> > performed immediately, which is sub-optimal in terms of timing, and
> >
Fei Li writes:
> Supplement the error handling for touch_all_pages: add an Error
> parameter for it to propagate the error to its caller to do the
> handling in case it fails.
>
> Cc: Markus Armbruster
> Signed-off-by: Fei Li
> ---
> util/oslib-posix.c | 25 -
> 1 file
On 1/7/19 11:50 AM, Max Reitz wrote:
Note I didn't set optreset. It's not present in glibc and the "hard
reset" is not necessary in this context.
>>>
>>> But it sure sounds like FreeBSD requires you to set it, doesn't it?
No. Quoting https://www.freebsd.org/cgi/man.cgi?getopt(3)
The problem seems to be that the PC we report for an OPCDEC is first selected
by gen_invalid()/gen-excp() in target/alpha/translate.c, which uses pc_next (ie
the insn's address plus 4). But that is then handed through to our custom
PALcode
Add a query command to check the status of the FAILOVER_STANDBY_CHANGED
state of the virtio_net devices.
Signed-off-by: Venu Busireddy
---
hw/net/virtio-net.c| 16
include/hw/virtio/virtio-net.h | 1 +
include/net/net.h | 2 ++
net/net.c
1 - 100 of 328 matches
Mail list logo
