On 19 June 2017 at 05:08, Emilio G. Cota wrote:
> On Sun, Jun 18, 2017 at 17:37:39 +0300, Lluís Vilanova wrote:
>> I kind of dislike it every time I see container_of, and it makes type
>> checking from the compiler a bit more fragile.
>
> container_of is *very* useful! You should like it more :-)
Am 18.06.2017 um 09:21 hat Xie Changlong geschrieben:
> In device hot-remove scenario, if we don't probe acpiphp module on
> the guest, 'device_del' will never emit DEVICE_DELETED event(because
> guest will not write to __EJ0) . So we can confirm that hot-remove
> failed. But IIUC, there is no even
The VT-d spec (section 6.5.2) prescribes software to zero the
Invalidation Queue Tail Register before enabling the VTD_GCMD_QIE
Global Command Register bit. Windows Server 2012 R2 and possibly
other older Windows versions violate the protocol and set a
non-zero queue tail first, which in effect mak
On Mon, Jun 19, 2017 at 8:42 AM, Peter Xu wrote:
> Since looks like we need another post, a tiny suggestion is that we
> can also add some comment to tell the reason why we didn't really
> check it, and a trace_vtd_warn_invalid_qi_tail() tracer to show that
> spec is violated (if you see, we have
On 06/19/2017 03:46 AM, Michael S. Tsirkin wrote:
What do you have in mind about the protocol flag?
Merely this: older clients might be confused if they get
a s/g with 1024 entries.
I don't disagree to add that. But the client (i.e. vhost-user
slave) is a host userspace program, and it seems t
Kamil Rytarowski writes:
> On 10.06.2017 17:15, Markus Armbruster wrote:
>> Kamil Rytarowski writes:
>>
>>> On 06.06.2017 16:56, Kamil Rytarowski wrote:
On 06.06.2017 16:34, Peter Maydell wrote:
> On 6 June 2017 at 14:38, Kamil Rytarowski wrote:
>> I've linked qemu with the origin
On 13.06.2017 14:55, Vadim Galitsyn wrote:
> Commands above provide the following memory information in bytes:
Is the idea to have something like hmp_info_numa() ("info NUMA"), just
for qmp? And so it also works without NUMA?
I think, for this command to be helpful, you should include a per-NUMA
On 16.06.2017 07:15, Richard Henderson wrote:
> Introduce a synthetic feature (type MISC) to handle disabling of
> the enforcing of features at translation time.
>
> Signed-off-by: Richard Henderson
> ---
> target/s390x/cpu_features.c | 4 +++-
> target/s390x/cpu_features_def.h | 1 +
> targ
Hi Eric,
I started added replay in virtio-iommu and came across how MSI interrupts with
work with VFIO.
I understand that on intel this works differently but vsmmu will have same
requirement.
kvm-msi-irq-route are added using the msi-address to be translated by viommu
and not the final transl
On 15.06.2017 22:37, Richard Henderson wrote:
> There are no uses in a Linux system with which to test,
> but it Looks Right by my reading of the PoO.
>
> Signed-off-by: Richard Henderson
> ---
> target/s390x/helper.h | 1 +
> target/s390x/insn-data.def | 2 +
> target/s390x/mem_helper.
On Mon, Jun 19, 2017 at 09:31:16AM +0200, Ladi Prosek wrote:
> The VT-d spec (section 6.5.2) prescribes software to zero the
> Invalidation Queue Tail Register before enabling the VTD_GCMD_QIE
> Global Command Register bit. Windows Server 2012 R2 and possibly
> other older Windows versions violate
Emilio G Cota writes:
> On Mon, Jun 19, 2017 at 00:54:05 +0300, Lluís Vilanova wrote:
>> Aha, just checked your proposed patches more closely and it totally makes
>> sense
>> to keep "is_jmp" to simplify the diffs, so I'll go for that one.
> Also I think it's important to break down the changes
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Thu, Jun 15, 2017 at 01:14:15PM +0100, Dr. David Alan Gilbert wrote:
> > * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > > This is being included in the RFC just to help validating the series,
> > > and ensure we don't use NULL errp anywhere.
>
On 06/18/17 22:23, Michael S. Tsirkin wrote:
> On Sun, Jun 18, 2017 at 09:02:14AM +0100, Mark Cave-Ayland wrote:
>> By exposing FWCfgIoState and FWCfgMemState internals we allow the possibility
>> for the internal MemoryRegion fields to be mapped by name for boards that
>> wish
>> to wire up the f
Peter Xu writes:
> On Fri, Jun 09, 2017 at 04:02:37PM +0200, Markus Armbruster wrote:
>> Test compile gripes:
>>
>> hw/xen/xen-common.c: In function ‘xen_init’:
>> hw/xen/xen-common.c:147:5: warning: implicit declaration of function
>> ‘register_compat_prop’ [-Wimplicit-function-declara
Eduardo Habkost writes:
> On Mon, Jun 12, 2017 at 12:46:09PM +0800, Peter Xu wrote:
>> On Fri, Jun 09, 2017 at 03:39:24PM +0200, Markus Armbruster wrote:
>> > Peter Xu writes:
>> >
>> > > Let the old man "MigrationState" join the object family. Direct benefit
>> > > is that we can start to use
Since commit 3f2ce724f1f1 ("Move the qemu-ga description into a
separate chapter"), the qemu.1 man page looks pretty much screwed
up, e.g. the title was "qemu-ga - QEMU Guest Agent" instead of
"qemu-doc - QEMU Emulator User Documentation". However, that movement
of the gemu-ga chapter is not the re
On 16.06.2017 18:19, Kevin Wolf wrote:
> Am 22.05.2017 um 22:53 hat Thomas Huth geschrieben:
>> The qemu-ga description is currently a subsection of the Disk Images
>> chapter - which does not make much sense since the qemu-ga is not
>> directly related to disk images. So let's move this informatio
On Sun, 18 Jun 2017 18:17:27 +0200
Tobias Schramm wrote:
Hi,
The patch titles are usually prefixed by the component name. Something like:
9pfs: local: add support for custom fmask/dmask in mapped security modes
Also, it is always nice to write a changelog, even if the feature looks simple.
At
Hi all,
I'm running `QEMU_CMD ...` to create a vm under dpdk huge page envriment
(which set huge page 1G). And I enable all events in qemu.
For qemu and ovs-dpdk(ovs-2.4.9 with dpdk-2.2.0) environment, detail log is:
> 30012@1497443246.678304:object_dynamic_cast_assert
qemu:memory-region->qemu:m
On 06/15/2017 03:33 PM, Peter Maydell wrote:
I've just noticed that on a SPARC host, some of the PPC guests
warn during make check:
/ppc64/prom-env/pseries:
qemu-system-ppc64: System page size 0x2000 is not enabled in
page_size_mask (0x11000). Performance may be slow
Is this really a perform
On 19 June 2017 at 09:48, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
>> On Thu, Jun 15, 2017 at 01:14:15PM +0100, Dr. David Alan Gilbert wrote:
>> > * Eduardo Habkost (ehabk...@redhat.com) wrote:
>> > > void visit_start_struct(Visitor *v, const char *name, void
On Mon, Jun 19, 2017 at 05:30:59PM +0800, Sam wrote:
> Hi all,
>
> I'm running `QEMU_CMD ...` to create a vm under dpdk huge page envriment
> (which set huge page 1G). And I enable all events in qemu.
Please provide the full QEMU command line you are using.
> For qemu and ovs-dpdk(ovs-2.4.9 with
On 15.06.2017 22:37, Richard Henderson wrote:
> There are no uses in a Linux system with which to test,
> but it Looks Right by my reading of the PoO.
I am using next.git/master with this patch applied:
https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features&id=8aa8680aa3
On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote:
> Important restrictions of this concept:
> - Guests without a virtio-mem guest driver can't see that memory.
> - We will always require some boot memory that cannot get unplugged.
> Also, virtio-mem memory (as all other hotplugge
On Thu, 8 Jun 2017 15:09:25 +1000
David Gibson wrote:
> PCI DRCs, and only PCI DRCs, are immediately moved to UNISOLATED isolation
> state once the device is attached. This has been there from the initial
> implementation, and it's not clear why.
>
> The state diagram in PAPR 13.4 suggests PCI
On Thu, 8 Jun 2017 15:09:26 +1000
David Gibson wrote:
> The 'signalled' field in the DRC appears to be entirely a torturous
> workaround for the fact that PCI devices were started in UNISOLATED state
> for unclear reasons.
>
> 1) 'signalled' is already meaningless for logical (so far, all non P
On 12/06/2017 16:48, Mao Zhongyi wrote:
Comments for pci_add_capability2() to explain the return
value. This may help to make a correct return value check
for its callers.
Cc: m...@redhat.com
Cc: mar...@redhat.com
Cc: arm...@redhat.com
Suggested-by: Markus Armbruster
Signed-off-by: Mao Zhongyi
On 19/06/17 08:54, Bharat Bhushan wrote:
> Hi Eric,
>
> I started added replay in virtio-iommu and came across how MSI interrupts
> with work with VFIO.
> I understand that on intel this works differently but vsmmu will have same
> requirement.
> kvm-msi-irq-route are added using the msi-addre
On Thu, 8 Jun 2017 15:09:27 +1000
David Gibson wrote:
> spapr_drc_detach() is called when qemu generic code requests a device be
> unplugged. It makes a number of tests, which could well delay further
> action until later, before actually detach the device from the DRC.
>
> This splits out the
On Thu, 8 Jun 2017 15:09:28 +1000
David Gibson wrote:
> The reset handler for DRCs attempts several state transitions which are
> subject to various checks and restrictions. But at reset time we know
> there is no guest, so we can ignore most of the usual sequencing rules and
> just set the DRC
On 19.06.2017 12:08, Stefan Hajnoczi wrote:
> On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote:
>> Important restrictions of this concept:
>> - Guests without a virtio-mem guest driver can't see that memory.
>> - We will always require some boot memory that cannot get unplugged.
>>
在 6/19/2017 3:27 PM, Kevin Wolf 写道:
Am 18.06.2017 um 09:21 hat Xie Changlong geschrieben:
In device hot-remove scenario, if we don't probe acpiphp module on
the guest, 'device_del' will never emit DEVICE_DELETED event(because
guest will not write to __EJ0) . So we can confirm that hot-remove
fai
On 19.06.2017 11:39, Alexander Graf wrote:
> On 06/15/2017 03:33 PM, Peter Maydell wrote:
>> I've just noticed that on a SPARC host, some of the PPC guests
>> warn during make check:
>>
>>/ppc64/prom-env/pseries:
>> qemu-system-ppc64: System page size 0x2000 is not enabled in
>> page_size_mask
We also include the an Emacs .dir-locals (as per QEMU) that enforces
this layout.
Signed-off-by: Alex Bennée
---
.dir-locals.el | 2 ++
README | 9 +
2 files changed, 11 insertions(+)
create mode 100644 .dir-locals.el
diff --git a/.dir-locals.el b/.dir-locals.el
new file mode 1
Signed-off-by: Alex Bennée
---
v5
- swap with docker patch so later can be dropped if not wanted
---
build-all-archs | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/build-all-archs b/build-all-archs
index 2768727..581a1b4 100755
--- a/buil
Hi,
Here is v5 of the RISU record/replay patches. The big changes are:
- new patch to sync coding standards
- handle stdin/out as a trace input/destination
- remove fprintf's from signal handlers
- swapped the static build flag with docker
I've left the "build with docker" patches in but
These are generated by the build-all-arches script.
Signed-off-by: Alex Bennée
Reviewed-by: Peter Maydell
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index fc84419..fca9128 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ risu
core
config
If we want to link to any other libraries we might find using simple
cross toolchains doesn't work so well. One way around this is to use a
dockerised cross-toolchain which then won't clash with your host
system. If the user specifies --use-docker the obvious will be done.
By default we use the QE
When debugging faults it is useful to know where the generated
instructions are living.
Signed-off-by: Alex Bennée
--
v5
- dropped all the status update due to signal handler contraints
v3
- use portable fmt string for image_start_address
- include arm dumping position
---
risu.c | 4
This is a precursor to record/playback support. Instead of passing the
socket fd we now pass helper functions for reading/writing and
responding. This will allow us to do the rest of the record/playback
cleanly outside of the main worker function.
Signed-off-by: Alex Bennée
---
v5
- re-base wi
A simple script to work through running all of a bunch of files with
record/playback traces. Dumps a summary and the number of failed tests
at the end.
Signed-off-by: Alex Bennée
---
v5
- author, license, usage header
v3
- tweak to allow specifying RISU binary
---
run_risu.sh | 66 +
I've also added a header packet with pc/risu op in it so we can keep
better track of how things are going.
Signed-off-by: Alex Bennée
---
v5
- re-base without formatting fixes
- dropped fprintfs in signal context
v4
- split from previous patch
---
reginfo.c | 94 +
Trace files can get quite large so it would be useful to be able to
just capture the trace stream with stdin/stdout for processing in a
pipe line. The sort of case where this is useful is for building
static binaries where zlib support is missing for whatever reason.
It can also be used in testing
This is pretty much a mechanical change where I ran:
indent -kr
Across all the files and then fixed up all but a few violations of:
../../qemu.git/scripts/checkpatch.pl -f *.c *.h > checkpatch.out
Along with heavy use of M-x untabify to make everything consistent.
Signed-off-by: Alex Benné
This adds a very dumb and easily breakable trace and replay support. In
--master mode the various risu ops trigger a write of register/memory
state into a binary file which can be played back to an apprentice.
Currently there is no validation of the image source so feeding the
wrong image will fail
This uses the magic of zlib's gzread/write interface to wrap the
tracefile in compression. The code changes are tiny. I spent more time
messing about with the configure/linker stuff to auto-detect bits.
As you need decent multi-arch support or a correctly setup cross
toolchain we fall back if we c
Philippe Mathieu-Daudé writes:
> to check each step elapsed time on the travis output report.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
> ---
> .travis.yml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index
Philippe Mathieu-Daudé writes:
> no improvement as of today, but if Travis release their limit on the
> opensource
> plan or upgrade their hardware the builds will get some benefit.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
> ---
> .travis.yml | 3 ++-
> 1 file cha
Am 19.06.2017 um 12:27 hat Xie Changlong geschrieben:
> 在 6/19/2017 3:27 PM, Kevin Wolf 写道:
> >Am 18.06.2017 um 09:21 hat Xie Changlong geschrieben:
> >>In device hot-remove scenario, if we don't probe acpiphp module on
> >>the guest, 'device_del' will never emit DEVICE_DELETED event(because
> >>gu
A simple script to run through a bunch of binaries and generate their
trace files.
Signed-off-by: Alex Bennée
---
v5
- author, license and usage header
v3
- allow overriding of RISU binary
---
record_traces.sh | 32
1 file changed, 32 insertions(+)
create m
On Fri, Jun 16, 2017 at 04:41:20PM +0100, Stephen Finucane wrote:
> On Fri, 2017-06-16 at 16:51 +0200, Kashyap Chamarthy wrote:
[...]
> As requested, a couple of rST pointers below that will help you if/when you
> switch to Sphinx. I've only focused on the design aspect, not the content.
Thanks
Philippe Mathieu-Daudé writes:
> all those objects can get compiled simultaneously
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> tests/Makefile.include | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index f
Philippe Mathieu-Daudé writes:
> so more codebase is built
>
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Alex Bennée
> ---
> .travis.yml | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/.travis.yml b/.travis.yml
> index 4889c192c2..4c0f7f444e 100644
> --- a/.travis.yml
Philippe Mathieu-Daudé writes:
> tests are run sequentially to avoid mixed results output.
I'm not so sure we are worried about mixed results output. I don't think
anyone can compare the entire log and they tend to scroll to the end
where the error will be.
>
> Signed-off-by: Philippe Mathieu-
Philippe Mathieu-Daudé writes:
> example of failure: https://travis-ci.org/qemu/qemu/jobs/243232857
>
> $ sudo apt-get update -qq
> W: Failed to fetch
> http://llvm.org/apt/trusty/dists/llvm-toolchain-trusty-3.9/Release.gpg
> Connection failed
> E: Some index files failed to downl
On 19 June 2017 at 11:58, Alex Bennée wrote:
>
> Philippe Mathieu-Daudé writes:
>
>> tests are run sequentially to avoid mixed results output.
>
> I'm not so sure we are worried about mixed results output. I don't think
> anyone can compare the entire log and they tend to scroll to the end
> wher
On 15/06/2017 18:54, Laurent Vivier wrote:
> On 14/06/2017 09:55, Peter Xu wrote:
>> 0425dc9 is actually v1 of that patch, but it was accidentally
>> merged (while there was a v2). That will cause problem when we try to
>> migrate to some old QEMUs when return path is not really there. Let's
>> fix
On 19.06.2017 09:42, Markus Armbruster wrote:
> Kamil Rytarowski writes:
>
>> On 10.06.2017 17:15, Markus Armbruster wrote:
>>> Kamil Rytarowski writes:
>>>
On 06.06.2017 16:56, Kamil Rytarowski wrote:
> On 06.06.2017 16:34, Peter Maydell wrote:
>> On 6 June 2017 at 14:38, Kamil Ryt
On 12/06/2017 16:48, Mao Zhongyi wrote:
Add Error argument for pci_add_capability() to leverage the errp
to pass info on errors. This way is helpful for its callers to
make a better error handling when moving to 'realize'.
Cc: pbonz...@redhat.com
Cc: r...@twiddle.net
Cc: ehabk...@redhat.com
Cc:
On 12/06/2017 16:48, Mao Zhongyi wrote:
After the patch 'Make errp the last parameter of pci_add_capability()',
pci_add_capability() and pci_add_capability2() now do exactly the same.
So drop the wrapper pci_add_capability() of pci_add_capability2(), then
replace the pci_add_capability2() with pc
On 12/06/2017 16:48, Mao Zhongyi wrote:
The pci-birdge device i82801b11
It is a dmi-to-pci brigde
and io3130_upstream/downstream
You forgot to mention the pcie_root_port.
still implements the old PCIDeviceClass .init() through *_init()
instead of the new .realize(). All devices need to be
On Fri 16 Jun 2017 05:31:42 PM CEST, Kevin Wolf wrote:
>> +/* Make sure that adding both COW regions to the QEMUIOVector
>> + * does not exceed IOV_MAX */
>> +if (hd_qiov->niov > IOV_MAX - 2) {
>> +continue;
>> +}
>> +
>> +m->data_qiov = hd_qiov;
Zoltan, Phil:
On Sun, Jun 18, 2017 at 11:25:15PM +0200, BALATON Zoltan wrote:
> After 77af8a2b9 (hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to
> improve guest OS support.) OS X 10.11.6 hangs during boot near detecting
> IOAPIC. (Gabriel's latest v3 applesmc patch series does not fix this.)
On 12/06/2017 16:48, Mao Zhongyi wrote:
In order to propagate error message better, convert shpc_init() to
Error also convert the pci_bridge_dev_initfn() to realize.
Cc: m...@redhat.com
Cc: mar...@redhat.com
Cc: arm...@redhat.com
Signed-off-by: Mao Zhongyi
---
hw/pci-bridge/pci_bridge_dev.c |
On 19.06.2017 12:03, David Hildenbrand wrote:
> On 15.06.2017 22:37, Richard Henderson wrote:
>> There are no uses in a Linux system with which to test,
>> but it Looks Right by my reading of the PoO.
>
> I am using next.git/master with this patch applied:
> https://git.kernel.org/pub/scm/linux/ke
On Thu, 8 Jun 2017 15:09:29 +1000
David Gibson wrote:
> The allocation-state indicator should only actually be implemented for
> "logical" DRCs, not physical ones. Factor a check for this, and also for
> valid indicator state values into rtas_set_allocation_state(). Because
> they don't exist
On 13/06/2017 22:48, Thomas Huth wrote:
This way the bridge shows up in the correct section of the
"-device help" text.
Signed-off-by: Thomas Huth
---
hw/pci-bridge/dec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/pci-bridge/dec.c b/hw/pci-bridge/dec.c
index cca9362..eb275e1 10
On Fri, Jun 16, 2017 at 05:03:48PM +0300, Michael S. Tsirkin wrote:
> On Fri, Jun 16, 2017 at 02:19:56PM +0100, Stefan Hajnoczi wrote:
> > On Fri, Jun 09, 2017 at 04:16:15PM +0100, Stefan Hajnoczi wrote:
> > > Commit e987c37aee1752177906847630d32477da57e705 ("hw/i386: check if
> > > nvdimm is enabl
On Fri, Jun 16, 2017 at 05:12:18PM +0300, Michael S. Tsirkin wrote:
> On Thu, Jun 15, 2017 at 05:38:09PM +0100, Stefan Hajnoczi wrote:
> > Old kvm.ko versions only supported a tiny number of ioeventfds so
> > virtio-pci avoids ioeventfds when kvm_has_many_ioeventfds() returns 0.
> >
> > Do not che
On 15.06.2017 19:38, Stefan Hajnoczi wrote:
This series extends qemu-iotests 068 to also run with iothread enabled. Doing
so was harder than expected because:
1. ioeventfd is disabled without -M accel=kvm even though it should work
2. loadvm still has an iothread bug
Instead of adding a ./chec
On 06/19/2017 02:05 PM, David Hildenbrand wrote:
> On 19.06.2017 12:03, David Hildenbrand wrote:
>> On 15.06.2017 22:37, Richard Henderson wrote:
>>> There are no uses in a Linux system with which to test,
>>> but it Looks Right by my reading of the PoO.
>>
>> I am using next.git/master with this p
On 18/06/17 21:23, Michael S. Tsirkin wrote:
> On Sun, Jun 18, 2017 at 09:02:14AM +0100, Mark Cave-Ayland wrote:
>> By exposing FWCfgIoState and FWCfgMemState internals we allow the possibility
>> for the internal MemoryRegion fields to be mapped by name for boards that
>> wish
>> to wire up the
On 16/06/2017 16:53, Igor Mammedov wrote:
On Wed, 14 Jun 2017 19:27:12 -0500
Michael Roth wrote:
Quoting Igor Mammedov (2017-06-14 04:00:01)
On Tue, 13 Jun 2017 16:42:45 -0500
Michael Roth wrote:
Quoting Igor Mammedov (2017-06-09 03:27:33)
[...]
But that raises a 2nd point. Our dile
On 19.06.2017 14:33, Christian Borntraeger wrote:
> On 06/19/2017 02:05 PM, David Hildenbrand wrote:
>> On 19.06.2017 12:03, David Hildenbrand wrote:
>>> On 15.06.2017 22:37, Richard Henderson wrote:
There are no uses in a Linux system with which to test,
but it Looks Right by my reading
On 19/06/17 09:57, Laszlo Ersek wrote:
> On 06/18/17 22:23, Michael S. Tsirkin wrote:
>> On Sun, Jun 18, 2017 at 09:02:14AM +0100, Mark Cave-Ayland wrote:
>>> By exposing FWCfgIoState and FWCfgMemState internals we allow the
>>> possibility
>>> for the internal MemoryRegion fields to be mapped by
Am 15.06.2017 um 18:38 hat Stefan Hajnoczi geschrieben:
> Avoid duplicating the QEMU command-line.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> tests/qemu-iotests/068 | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/tests/qemu-iotests/068 b/tests/qemu-iotests
On 06/19/2017 02:41 PM, David Hildenbrand wrote:
> On 19.06.2017 14:33, Christian Borntraeger wrote:
>> On 06/19/2017 02:05 PM, David Hildenbrand wrote:
>>> On 19.06.2017 12:03, David Hildenbrand wrote:
On 15.06.2017 22:37, Richard Henderson wrote:
> There are no uses in a Linux system wit
We have HW_COMPAT_*, however that's only binded to machines, not other
things (like accelerators). Behind it, it was register_compat_prop()
that played the trick. Let's export the function for further use
outside HW_COMPAT_* magic.
Meanwhile, move it to qdev-properties.c where seems more proper.
Originally it can only alloc new entries and insert. Let it be smarter
that it can update existing fields, and even delete elements. This is
preparation of (finally) the replacement of x86_cpu_apply_props(). If
you see x86_cpu_apply_props(), it allows to skip entries when value is
NULL. Here, it wo
v3 contains too much new things. So here comes a new cover letter with
richer information.
The main goal of this series is to let MigrationState be a QDev.
It helps in many use cases.
First of all, we can remove many legacy tricky functions. To name
some: savevm_skip_section_footers(), savevm_sk
It works very similar to register_compat_prop() but does not need a
malloc, however mostly all the callers of it are doing malloc on their
own. Then it makes little sense to keep it.
Replacing all the callers with register_compat_prop(), meanwhile adding
one more parameter "user_provided" for it t
After previous patch to let qdev_prop_register_global_list() use
register_compat_prop(), then caller won't be guaranteed that the
GlobalProperty pointer passed in will be the one linked to global_props
list (now we always alloc new GlobalProperty for it). So prop->used will
never be set.
Let's avo
Introduce this new field for the accelerator instances so that each
specific accelerator in the future can register its own global
properties to be used further by the system. It works just like how the
old machine compatible properties do, but only tailored for
accelerators.
Use the newly export
Let tcg use the new AccelState.global_props as well (used similar trick
for the kvm convertion in previous patch). Basically we are moving the
tcg_default_props into tcg codes, and link these compat properties onto
newly created AccelState.global_props.
This is much simpler than KVM.
Signed-off-b
Let KVM be the first user of the new AccelState.global_props field.
Basically kvm accel only contains accel props for TYPE_X86_CPUs but not
anything else yet.
There will be a change on how these global properties are applied for
TYPE_X86_CPU devices. The general workflow of the global property stu
Trace global property applying. Now there are machine compat properties,
accel compat properties, and user specified global properties. It
provides a way to trace those properties that really applied.
Signed-off-by: Peter Xu
---
Makefile.objs | 1 +
hw/core/qdev-properties.c | 2 ++
Am 15.06.2017 um 18:38 hat Stefan Hajnoczi geschrieben:
> This series extends qemu-iotests 068 to also run with iothread enabled. Doing
> so was harder than expected because:
>
> 1. ioeventfd is disabled without -M accel=kvm even though it should work
> 2. loadvm still has an iothread bug
>
> In
Put it into MigrationState then we can use the properties to specify
whether to enable storing global state.
Removing global_state_set_optional() since now we can use HW_COMPAT_2_3
for x86/power, and accel_register_prop() for xen_init().
Signed-off-by: Peter Xu
---
hw/i386/pc_piix.c
Let the old man "MigrationState" join the object family. Direct benefit
is that we can start to use all the property features derived from
current QDev, like: HW_COMPAT_* bits, command line setup for migration
parameters (so will never need to set them up each time using HMP/QMP,
this is really, re
On 19.06.2017 14:47, Christian Borntraeger wrote:
> On 06/19/2017 02:41 PM, David Hildenbrand wrote:
>> On 19.06.2017 14:33, Christian Borntraeger wrote:
>>> On 06/19/2017 02:05 PM, David Hildenbrand wrote:
On 19.06.2017 12:03, David Hildenbrand wrote:
> On 15.06.2017 22:37, Richard Hender
One less global variable, and it does only matter with migration.
We keep the old "--only-migratable" option, but also now we support:
-global migration.only-migratable=true
Currently still keep the old interface.
Hmm, now vl.c has no way to access migrate_get_current(). Export a
function for
Move it into MigrationState, revert its meaning and renaming it to
send_section_footer, with a property bound to it. Same trick is played
like previous patches.
Removing savevm_skip_section_footers().
Signed-off-by: Peter Xu
---
hw/i386/pc_piix.c| 1 -
hw/ppc/spapr.c | 1 -
As indicated by Laszlo it is a QOM bug for the realize() method to actually
map the device. Set up the IO regions within fw_cfg_io_realize() and defer
the mapping with sysbus_add_io() to the caller, as already done in
fw_cfg_init_mem_wide().
This makes the iobase and dma_iobase properties now obso
In preparation for calling fw_cfg_init1() during realize rather than during
init, move the assert() checking for existing fw_cfg devices and the linking
of the device to the machine with object_property_add_child() to a new
fw_cfg instance_init() function.
This guarantees that we will still assert
It was in SaveState but now moved to MigrationState altogether, reverted
its meaning, then renamed to "send_configuration". Again, using
HW_COMPAT_2_3 for old PC/SPAPR machines, and accel_register_prop() for
xen_init().
Removing savevm_skip_configuration().
Signed-off-by: Peter Xu
---
hw/i386/p
By exposing FWCfgIoState and FWCfgMemState internals we allow the possibility
for the internal MemoryRegion fields to be mapped by name for boards that wish
to wire up the fw_cfg device themselves.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Laszlo Ersek
Tested-by: Laszlo Ersek
---
hw/nvram/f
As part of some ongoing sun4u work, I need to be able to wire the fw_cfg
IO interface to a separate IO space by instantiating the qdev device instead
of calling fw_cfg_init_io(). This patchset brings FW_CFG_IO in line with
FW_CFG_MEM and tidies up the realize methods accordingly.
Signed-off-by: Ma
On 06/19/2017 02:52 PM, David Hildenbrand wrote:
> On 19.06.2017 14:47, Christian Borntraeger wrote:
>> On 06/19/2017 02:41 PM, David Hildenbrand wrote:
>>> On 19.06.2017 14:33, Christian Borntraeger wrote:
On 06/19/2017 02:05 PM, David Hildenbrand wrote:
> On 19.06.2017 12:03, David Hilde
The setting of the FW_CFG_VERSION_DMA bit is the same across both the
TYPE_FW_CFG_MEM and TYPE_FW_CFG_IO devices, so unify the logic in
fw_cfg_init1().
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Laszlo Ersek
Tested-by: Laszlo Ersek
---
hw/nvram/fw_cfg.c | 16 +++-
1 file change
1 - 100 of 270 matches
Mail list logo
