Reviewed-by: Dmitry Fleytman mailto:dmi...@daynix.com>>
> On 8 Dec 2015, at 07:28 AM, Miao Yan wrote:
>
> This patchset fixes debug macro pattern for vmxnet3. The old style uses
> #ifdef...#else...#endif to define debug macros, as a result
> the format string inside the macro will never be chec
Macro VMW_SHPRN(...) is already defined vmxnet3_debug.h,
so remove the duplication
Signed-off-by: Miao Yan
Reviewed-by: Eric Blake
---
hw/net/vmware_utils.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/hw/net/vmware_utils.h b/hw/net/vmware_utils.h
index 1099df6..c2c2f
Macro MAC_FMT and MAC_ARG are not defined, but used in vmxnet3_net_init().
This will cause build error when debug level is raised in
vmxnet3_debug.h (enable all VMXNET3_DEBUG_xxx).
Use VMXNET_MF and VXMNET_MA instead.
Signed-off-by: Miao Yan
Reviewed-by: Eric Blake
---
Changes in v3:
- add Re
Vmxnet3 uses the following debug macro style:
#ifdef SOME_DEBUG
# define debug(...) do{ printf(...); } while (0)
# else
# define debug(...) do{ } while (0)
#endif
If SOME_DEBUG is undefined, then format string inside the
debug macro will never be checked by compiler. Code is
likely to brea
Use %zu specifier for size_t in printf, otherwise build would fail
on platforms where size_t is not unsigned long
Signed-off-by: Miao Yan
---
hw/net/vmxnet3.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index ea3d9b7..e168285 1006
This patchset fixes debug macro pattern for vmxnet3. The old style uses
#ifdef...#else...#endif to define debug macros, as a result
the format string inside the macro will never be checked
(debug not turned on by default) and is likely to cause build
errors in the future when enabled.
Changes in
Has anyone seen anything like this ? all 4 qemu threads are stuck on a
pthread condition
QEMU emulator version 2.2.0 (Debian 1:2.2+dfsg-5expubuntu9.3~cloud0), Copyright
(c) 2003-2008 Fabrice Bellard
I'll try and get the qemu source built on this machine to debug and get
some useful symbols out
Returning a partial object on error is an invitation for a careless
caller to leak memory. As no one outside the testsuite was actually
relying on these semantics, it is cleaner to just document and
guarantee that ALL pointer-based visit_type_FOO() functions always
leave a safe value in *obj durin
By sticking the next pointer first, we don't need a union with
64-bit padding for smaller types. On 32-bit platforms, this
can reduce the size of uint8List from 16 bytes (or 12, depending
on whether 64-bit ints can tolerate 4-byte alignment) down to 8.
It has no effect on 64-bit platforms (where a
We have two uses of list visits in the entire code base: one in
spapr_drc (which completely avoids visit_next_list(), feeding in
integers from a different source than uint8List), and one in
qapi-visit.py (that is, all other list visitors are generated
in qapi-visit.c, and share the same paradigm ba
The generator special-cased
{ 'command':'foo', 'data': {} }
to avoid emitting a visitor variable, but failed to see that
{ 'struct':'NamedEmptyType, 'data': {} }
{ 'command':'foo', 'data':'NamedEmptyType' }
needs the same treatment. Without a fix to the generator, the
change to qapi-schema-test
Now that the QMP output visitor supports an explicit null
output, we should utilize it to make it easier to diagnose
the difference between a missing fdt vs. a present-but-empty
one.
(Note that this reverts the behavior of commit ab8bf1d, taking
us back to the behavior of commit 1d10b44; but that
Now that we elide unnecessary visits of empty types, we can
start using the special ':empty' type in more places. By using
the empty type as the base class of every explicit struct or
union, and as the default data for any command or event, we can
simplify later logic in qapi-{visit,commands,event
As mentioned in previous patches, we want to call visit_end_struct()
functions unconditionally, so that visitors can release resources
tied up since the matching visit_start_struct() without also having
to worry about error priority if more than one error occurs.
Even though error_propagate() can
When reporting that an unvisited member remains at the end of an
input visit for a struct, we were using g_hash_table_find()
coupled with a callback function that always returns true, to
locate an arbitrary member of the hash table. But if all we
need is an arbitrary entry, we can get that from a
And use it in qapi-types and qapi-event. Down the road, we may
want to lift our artificial restriction of no variants at the
top level of an event, at which point, inlining our check for
whether members is empty will no longer be sufficient. More
immediately, the new .is_empty() helper will help
We are finally at the point where gen_visit_struct() and
gen_visit_union() can be unified to a generic gen_visit_object().
The generated code for structs and for flat unions is unchanged.
For simple unions, a new visit_type_FOO_fields() is created,
wrapping the visit of the non-variant tag field:
The visitor interface for mapping between QObject/QemuOpts/string
and qapi has formerly been documented only by reading source code,
making it difficult to propose changes to either scripts/qapi*.py
or to clients without knowing whether those changes would be safe.
This adds documentation, includin
Commit cee2dedb noticed that if you have a partial flat union
(such as if an input parse failed due to a missing
discriminator), calling the dealloc visitor could result in
trying to dereference the NULL pointer. But the fix it proposed
requires the use of a 'data' member in the union, which may or
For empty structs, such as the 'Abort' helper type used as part
of the 'transaction' command, we were emitting a no-op
visit_type_FOO_fields(). Optimize things to instead omit calls
for empty structs. Generated code changes resemble:
|-static void visit_type_Abort_fields(Visitor *v, Abort **obj,
Add a new qmp_output_reset(), which must be called before reusing
an exising QmpOutputVisitor on a new root object. Tighten
assertions to require that qmp_output_get_qobject() can only
be called after pairing a visit_end_* for every visit_start_*
(rather than allowing it to return a partially buil
visit_start_struct() and visit_type_enum() had a 'kind' argument
that was usually set to either the stringized version of the
corresponding qapi type name, or to NULL (although some clients
didn't even get that right). But nothing ever used the argument.
It's even hard to argue that it would be us
Commit 6c2f9a15 ensured that we would not return NULL when the
caller used an output visitor but had nothing to visit. But
in doing so, it added a FIXME about a reference count leak
that could abort qemu in the (unlikely) case of SIZE_MAX such
visits (more plausible on 32-bit). (Although that comm
The previous commit documented an inconsistency in how we are
using the stack of qmp-output-visitor. Normally, pushing a
single top-level object puts the object on the stack twice:
once as the root, and once as the current container being
appended to; but popping that struct only pops once. Howev
The qapi builtin type 'int' is basically shorthand for the type
'int64'. In fact, since no visitor was providing the optional
type_int64() callback, visit_type_int64() was just always falling
back to type_int(), cementing the equivalence between the types.
However, some visitors are providing a t
Commit 4e27e819 introduced optional visitor callbacks for all
sorts of int types, but no visitor has supplied any of the
callbacks for sizes less than 64 bits. In other words, the
generic implementation based on using type_[u]int64() followed
by bounds-checking works just fine. In the interest of
No backend was setting an error when ending the visit of a list
or implicit struct. Make the callers a bit easier to follow by
making this a part of the contract, and removing the errp
argument - callers can then unconditionally end an object as
part of cleanup without having to think about whethe
Inside the generated code between visit_start_struct() and
visit_end_struct(), we were blindly setting the error into
the caller's errp parameter. But a future patch to split
visit_end_struct() will require that we take action based
on whether an error has occurred, which requires us to track
all
All other successful clients of visit_start_struct() were paired
with an unconditional visit_end_struct(); but the generated
code for events was relying on qmp_output_visitor_cleanup() to
work on an incomplete visit. Alter the code to guarantee that
the struct is completed, which will make a futur
Right now, qmp-output-visitor happens to produce a QNull result
if nothing is actually visited between the creation of the visitor
and the request for the resulting QObject. A stronger protocol
would require that a QMP output visit MUST visit something. But
to still be able to produce a JSON 'nul
C compilers are allowed to represent enums as a smaller type
than int, if all enum values fit in the smaller type. There
are even compiler flags that force the use of this smaller
representation, and using them changes the ABI of a binary.
Therefore, our generated code for visit_type_ENUM() (for a
Pending prerequisites:
+ Markus' qapi-not-next branch (including my subset D patches)
http://repo.or.cz/qemu/armbru.git/shortlog/refs/heads/qapi-not-next
https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg00463.html
Also available as a tag at this location:
git fetch git://repo.or.cz/qemu/er
Our qapi visitor contract supports multiple integer visitors,
but left the type_uint64 visitor as optional (falling back on
type_int64); it also marks the type_size visitor as optional
(falling back on type_uint64 or even type_int64).
Note that the default of falling back on type_int for unsigned
The macro DO_UPCAST() is incorrectly named: it converts from a
parent class to a derived class (which is a downcast). Better,
and more consistent with some of the other qapi visitors, is
to use the container_of() macro through a to_FOO() helper.
Our current definition of container_of() is weaker
We've already documented that our JSON parsing is locale dependent;
but we should also document that our JSON output has the same
problem. Additionally, JSON requires finite values (you have to
upgrade to JSON5 to get support for Inf or NaN), and our output
risks truncating floating point numbers
Cache the visitor in a local variable instead of repeatedly
calling the accessor. Pass NULL for the visit_start_struct()
object (which matches the fact that we were already passing 0
for the size argument, because we aren't using the visit to
allocate a qapi struct).
Signed-off-by: Eric Blake
-
Rework the control flow of balloon_stats_get_all() to make it
easier for a later patch to split visit_end_struct(). Also
switch to the uint64 visitor to match the data type.
Signed-off-by: Eric Blake
---
v7: place earlier in series
v6: new patch, split from RFC on v5 7/46
---
hw/virtio/virtio-
Commit 0b9d8542 added StackEntry.is_list_head, but forgot to
delete the now-unused QapiDeallocVisitor.is_list_head.
Signed-off-by: Eric Blake
---
v7: new patch
---
qapi/qapi-dealloc-visitor.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/qapi/qapi-dealloc-visitor.c b/qapi/qapi-dealloc-visi
Cache the visitor in a local variable instead of repeatedly
calling the accessor. Pass NULL for the visit_start_struct()
object (which matches the fact that we were already passing 0
for the size argument, because we aren't using the visit to
allocate a qapi struct). Guarantee that visit_end_stru
2015-12-08 6:04 GMT+08:00 Eric Blake :
> On 12/06/2015 07:47 PM, Jason Wang wrote:
>>
>>
>> On 12/05/2015 04:55 PM, Miao Yan wrote:
>>> Vmxnet3 uses the following debug macro style:
>>>
>>> #ifdef SOME_DEBUG
>>> # define debug(...) do{ printf(...); } while (0)
>>> # else
>>> # define debug(..
I know MAX_CODE_GEN_BUFFER_SIZE is limited by the host direct branch
instructions.But the arm's MAX_CODE_GEN_BUFFER_SIZE is so small.I
tried improving MAX_CODE_GEN_BUFFER_SIZE.I wrote some check codes for
the overflow offset in tcg_out_b(), tcg_out_bl(),
tcg_out_blx_imm(),reloc_pc24(). But I didn't
On Mon, Dec 07, 2015 at 02:34:37PM +1100, David Gibson wrote:
> At the moment all the class_init functions and TypeInfo structures for the
> various versioned pseries machine types are open-coded. As more versions
> are created this is getting increasingly clumsy.
>
> This patch borrows the appro
On Mon, Dec 07, 2015 at 03:13:02PM -0700, Eric Blake wrote:
> On 12/06/2015 10:56 PM, Peter Xu wrote:
> > - patch 8
> > - add "DumpQueryResult" in DUMP_COMPLETED event [Eric]
> > (since DumpQueryResult is introduced in patch 10, so doing it in
> > patch 10 for convenience. Please let me k
On Mon, 12/07 17:42, Cornelia Huck wrote:
> On Mon, 7 Dec 2015 11:02:51 +0100
> Cornelia Huck wrote:
>
> > On Thu, 3 Dec 2015 13:00:00 +0800
> > Stefan Hajnoczi wrote:
> >
> > > From: Fam Zheng
> > >
> > > The assertion problem was noticed in 06c3916b35a, but it wasn't
> > > completely fixed
On Mon, 12/07 21:02, Fam Zheng wrote:
> On Mon, 12/07 12:29, Cornelia Huck wrote:
> > No general objection to removing x-data-plane; but this probably wants
> > a mention on the changelog as x-data-plane has been described in
> > various howtos etc. over the years.
Add a changelog line,
http://wi
On 2015年12月07日 15:38, Hailiang Zhang wrote:
On 2015/12/3 15:21, Yang Hongyang wrote:
On 2015年12月03日 14:48, Hailiang Zhang wrote:
On 2015/12/3 14:25, Wen Congyang wrote:
On 12/03/2015 11:53 AM, Hailiang Zhang wrote:
On 2015/12/3 9:17, Wen Congyang wrote:
On 11/24/2015 05:25 PM, zhanghailian
On Mon, 12/07 17:19, Vladimir Sementsov-Ogievskiy wrote:
> On 07.12.2015 08:59, Fam Zheng wrote:
> >Vladimir,
> >
> >This is what I propose to implement meta bitmap. It's implemented in the
> >HBitmap level to be more efficient, and the interface slightly varies too.
>
> What is the benefit?
>
>
On Mon, 12/07 18:47, John Snow wrote:
>
>
> On 12/07/2015 12:59 AM, Fam Zheng wrote:
> > Vladimir,
> >
> > This is what I propose to implement meta bitmap. It's implemented in the
> > HBitmap level to be more efficient, and the interface slightly varies too.
> >
>
> I missed it: What was wrong
On Mon, 12/07 16:32, Vladimir Sementsov-Ogievskiy wrote:
> On 07.12.2015 08:59, Fam Zheng wrote:
> >The meta bitmap will have the same size and granularity as the tracked
> >bitmap, and upon each bit toggle, the corresponding bit in the meta
> >bitmap, at an identical position, will be set.
>
> No
Hi, Marcel
On 12/07/2015 09:42 PM, Marcel Apfelbaum wrote:
On 12/07/2015 10:08 AM, Cao jin wrote:
There are many PCI devices still using .init() as its initialization
function,
I am planning to do the "convert to realize()" work, and PCI bridge
devices are
chosen first. The supporting functions
On 12/07/2015 05:18 PM, David Gibson wrote:
> On Fri, Dec 04, 2015 at 11:11:31AM +0100, Markus Armbruster wrote:
>> David Gibson writes:
>>
It was {} in 2.4. Changing it to null so we can distingish "nothing"
from "empty" is an incompatible change. May make sense anyway, but I
ca
On Fri, Dec 04, 2015 at 11:11:31AM +0100, Markus Armbruster wrote:
> David Gibson writes:
>
> > On Fri, Dec 04, 2015 at 09:05:51AM +0100, Markus Armbruster wrote:
> >> David Gibson writes:
> >>
> >> > On Thu, Dec 03, 2015 at 04:30:31PM +0100, Markus Armbruster wrote:
> >> >> 1. Before commit 94
Hello,
On behalf of the QEMU Team, I'd like to announce the availability of the
fourth release candidate for the QEMU 2.5 release. This release is meant
for testing purposes and should not be used in a production environment.
http://wiki.qemu.org/download/qemu-2.5.0-rc3.tar.bz2
You can help i
On 12/07/2015 04:34 PM, John Snow wrote:
> This patch adds a new explicit Floppy Drive Type option. The existing
> behavior in QEMU is to automatically guess a drive type based on the
> media inserted, or if a diskette is not present, arbitrarily assign one.
>
> This behavior can be described as "
On 12/07/2015 12:59 AM, Fam Zheng wrote:
> Vladimir,
>
> This is what I propose to implement meta bitmap. It's implemented in the
> HBitmap level to be more efficient, and the interface slightly varies too.
>
I missed it: What was wrong with Vladimir's approach / what are the
benefits of this
On Mon, Nov 30, 2015 at 2:57 PM, Frederic Konrad
wrote:
> On 24/11/2015 04:42, Alistair Francis wrote:
>> On Mon, Nov 23, 2015 at 6:53 PM, KONRAD Frederic
>> wrote:
>>>
>>> Le 20/11/2015 13:21, Alistair Francis a écrit :
On Fri, Oct 16, 2015 at 7:11 PM, wrote:
> From: KONRAD Frederic
2.88MB capable drives can accept 1.44MB floppies,
for instance. To rework the pick_geometry function,
we need to know if our current drive can even accept
the type of disks we're considering.
NB: This allows us to distinguish between all of the
"total sectors" collisions between 1.20MB and 1.44MB
Respect the drive type as given via the CLI.
Set the type given by the CLI during fd_init. If the type remains the
default (auto), we'll attempt to scan an inserted diskette if present
to determine a type. If auto is selected but no diskette is present,
we fall back to a predetermined default (cur
This patch adds a new explicit Floppy Drive Type option. The existing
behavior in QEMU is to automatically guess a drive type based on the
media inserted, or if a diskette is not present, arbitrarily assign one.
This behavior can be described as "auto." This patch adds explicit
behaviors: 120, 144
The 2.88 drive is more suitable as a default because
it can still read 1.44 images correctly, but the reverse
is not true.
Since there exist virtio-win drivers that are shipped on
2.88 floppy images, this patch will allow VMs booted without
a floppy disk inserted to later insert a 2.88MB floppy an
This one is the crazy one.
fd_revalidate currently uses pick_geometry to tell if the diskette
geometry has changed upon an eject/insert event, but it won't allow us
to insert a 1.44MB diskette into a 2.88MB drive. This is inflexible.
The new algorithm applies a new heuristic to guessing disk geom
Currently, fd_revalidate is called in two different places, with two
different expectations of behavior:
(1) On initialization, as a routine to help pick the drive type and
initial geometries as a side-effect of the pick_geometry routine
(2) On insert/eject, which either sets the geometries t
Yes, it's been broken for ten years.
No, it's not a CVE.
The problem is that QEMU doesn't have a configuration option for the type
of floppy drive you want. It determines that based on the type of
diskette inserted at boot time.
If you don't insert one, it always chooses a 1.44MB type.
If you wa
The old test assumes a 1.44MB drive.
Assert that the QEMU default drive is now either 1.44 or 2.88.
Signed-off-by: John Snow
---
tests/fdc-test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fdc-test.c b/tests/fdc-test.c
index b5a4696..526d459 100644
--- a/tests/fdc-
Code motion: I want to refactor this function to work with FDrive
directly, so shuffle it below that definition.
Signed-off-by: John Snow
---
hw/block/fdc.c | 90 +-
1 file changed, 45 insertions(+), 45 deletions(-)
diff --git a/hw/block/f
Modify this function to operate directly on FDrive objects instead of
unpacking and passing all of those parameters manually.
Helps reduce complexity in each caller, and reduces the number of args.
Signed-off-by: John Snow
---
hw/block/fdc.c | 54 +++-
This allows us to distinguish between the current disk type and the
current drive type. The drive is what's reported to CMOS, the disk is
whatever the pick_geometry function suspects has been inserted.
The drive field maintains the exact same meaning as it did previously,
however pick_geometry/fd_
With this i.MX25 and i.MX31 to have close implementation.
Moreover all i.MX31 CCM registers are now present
Signed-off-by: Jean-Christophe Dubois
---
Changes since v1:
* Not present
Changes since v2:
* Not present
Changes since v3:
* Not present
Changes since v4:
* Not present
Changes s
The IMX_CCM class is now the base abstract class that is used by EPIT and GPT
timer implementation.
IMX31_CCM class is the concrete class implementing CCM for i.MX31 SOC.
For now the i.MX25 continues to use the i.MX31 CCM implementation.
An i.MX25 specific CCM will be introduced in a later patch
With this CCM, i.MX25 timer is accurate with "real world time".
Signed-off-by: Jean-Christophe Dubois
Reviewed-by Peter Crosthwaite
---
Changes since v1:
* rework loging to match other i.MX drivers
Changes since v2:
* We moved to an inheritance QOM scheme
Changes since v3:
* Rework logging
Linux on i.MX31/KZM is expecting the CCM to use the CKIH ref clock instead
of the CKIL plus the FPM multiplier.
We change the CCMR reg reset value to match linux expected config.
This allow the CCM to provide a 39MHz clk (as expected by linux) instead of
the actual 50MHz.
With this change the "s
i.MX25 SOC has a different CCM device than i.MX31.
Qemu i.MX25 emulation was built with i.MX31 CCM driver. This allows
Linux to work on top of the i.MX25 emultion but this is not correct.
Furthermore, other SOC we could emulate like i.MX6 have yet a different
implementation of the CCM device.
So
This is to prepare for CCM code refactoring.
This is just a bit of function and enum values renaming.
We also remove some useless intermediate variables.
Signed-off-by: Jean-Christophe Dubois
Reviewed-by: Peter Crosthwaite
---
Changes since v1:
* Not present
Changes since v2:
* Not pres
On 12/07/2015 02:25 AM, Stewart Smith wrote:
> Cédric Le Goater writes:
>> On 11/28/2015 08:59 AM, Benjamin Herrenschmidt wrote:
>>> On Fri, 2015-11-27 at 11:21 +0100, Alexander Graf wrote:
How does real hardware store petitboot? If it's flash, you could pass it
in using -pflash and
On 12/06/2015 10:56 PM, Peter Xu wrote:
> v5 changes:
> - patch 1
> - comment English fix [Fam]
> - patch 2
> - pass has_detach=true always in hmp_dump_guest_memory [Paolo]
> - patch 3
> - always use local_err and error_propagate() when need to check
> the result [Fam]
> - patch 8
> - a
Will do.
Thanks,
Matt
> On Dec 5, 2015, at 2:00 AM, Jan Kiszka wrote:
>
> On 2015-11-14 00:25, Matt Gingell wrote:
>> Hi,
>>
>> The following patches adds support for the new KVM split irqchip
>> interface discussed on the KVM mailing list.
>>
>> [kvm] KVM: x86: Split the APIC from the rest
On 12/06/2015 07:47 PM, Jason Wang wrote:
>
>
> On 12/05/2015 04:55 PM, Miao Yan wrote:
>> Vmxnet3 uses the following debug macro style:
>>
>> #ifdef SOME_DEBUG
>> # define debug(...) do{ printf(...); } while (0)
>> # else
>> # define debug(...) do{ } while (0)
>> #endif
>>
>> If SOME_DEBU
Hi all,
I was testing out the "qemu-img info/convert" options in combination with
"http/https" when I stumbled upon this issue. When "qemu-img info/convert" tries
to collect the file info it will first try to fetch the Content-Size of the
remote file. It does a HEAD request and after a GET request
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, 7 December 2015 01:53
> On 07/12/2015 06:20, Andrew Baumann wrote:
> > Yeah, I considered doing that, but figured that those cases
> > (incorrectly-sized register writes in 16-bit mode) are indicativ
On 07.12.2015 19:11, Denis V. Lunev wrote:
> On 12/07/2015 08:54 PM, Eric Blake wrote:
>> On 12/07/2015 10:51 AM, Eric Blake wrote:
>>> [adding qemu-devel - ALL patches should go to qemu-devel, even if they
>>> are also going to a sub-list like qemu-block]
>>>
>>> On 12/07/2015 10:07 AM, Roman Kaga
On 12/02/2015 03:46 AM, Eduardo Habkost wrote:
This moves all data from PcGuestInfo to either PCMachineState or
PCMachineClass.
This series depends on other two series:
* [PATCH v3 0/6] pc: Initialization and compat function cleanup
* [PATCH V3 0/3] hw/pcie: Multi-root support for Q35
For refe
On Mon, Dec 7, 2015 at 9:39 AM, Michael S. Tsirkin wrote:
> On Mon, Dec 07, 2015 at 09:12:08AM -0800, Alexander Duyck wrote:
>> On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
>> > On 12/5/2015 1:07 AM, Alexander Duyck wrote:
>> > If can't do that, we have to stop DMA in a short time to mark
On 12/07/2015 08:54 PM, Eric Blake wrote:
On 12/07/2015 10:51 AM, Eric Blake wrote:
[adding qemu-devel - ALL patches should go to qemu-devel, even if they
are also going to a sub-list like qemu-block]
On 12/07/2015 10:07 AM, Roman Kagan wrote:
qcow2_get_specific_info() used to have a code path
On 12/07/2015 10:51 AM, Eric Blake wrote:
> [adding qemu-devel - ALL patches should go to qemu-devel, even if they
> are also going to a sub-list like qemu-block]
>
> On 12/07/2015 10:07 AM, Roman Kagan wrote:
>> qcow2_get_specific_info() used to have a code path which would leave
>> pointer to Im
[adding qemu-devel - ALL patches should go to qemu-devel, even if they
are also going to a sub-list like qemu-block]
On 12/07/2015 10:07 AM, Roman Kagan wrote:
> qcow2_get_specific_info() used to have a code path which would leave
> pointer to ImageInfoSpecificQCow2 uninitialized.
>
> We guess th
On Mon, Dec 07, 2015 at 09:12:08AM -0800, Alexander Duyck wrote:
> On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
> > On 12/5/2015 1:07 AM, Alexander Duyck wrote:
> >>>
> >>>
> >>> We still need to support Windows guest for migration and this is why our
> >>> patches keep all changes in the dr
> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
> Sent: Sunday, 6 December 2015 22:37
> On Thu, Dec 3, 2015 at 10:01 PM, Andrew Baumann
> wrote:
> > This adds the system mailboxes which are used to communicate with a
> > number of GPU peripherals on Pi/Pi2.
> >
>
> Are there any pub
On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
> On 12/5/2015 1:07 AM, Alexander Duyck wrote:
>>>
>>>
>>> We still need to support Windows guest for migration and this is why our
>>> patches keep all changes in the driver since it's impossible to change
>>> Windows kernel.
>>
>>
>> That is a p
On 7 December 2015 at 15:19, Paolo Bonzini wrote:
>
>
> On 07/12/2015 14:02, Fam Zheng wrote:
>> On Mon, 12/07 12:29, Cornelia Huck wrote:
>>> On Mon, 7 Dec 2015 18:59:27 +0800
>>> Fam Zheng wrote:
>>>
The official way of enabling dataplane is through the "iothread"
property that refer
On Tue, Nov 24, 2015 at 09:35:17PM +0800, Lan Tianyu wrote:
> This patchset is to propose a solution of adding live migration
> support for SRIOV NIC.
I thought about what this is doing at the high level, and I do have some
value in what you are trying to do, but I also think we need to clarify
th
On Mon, 7 Dec 2015 16:33:11 +
Peter Maydell wrote:
> On 7 December 2015 at 16:27, Cornelia Huck wrote:
> > On Mon, 7 Dec 2015 16:50:01 +0100
> > Cornelia Huck wrote:
> >
> >> For x-data-plane=true, we create an iothread automatically for
> >> compatibility. Commit d21e877 ("iothread: inclu
>>> On 07.12.15 at 13:41, wrote:
> I know that in your opinion is superfluous, nonetheless could you please
> add 2-3 lines of in-code comment right here, to explain what you are
> doing with the check? Something like:
>
> /*
> * Update the entry addr and data to the latest values only when the
On Mon, 7 Dec 2015 11:02:51 +0100
Cornelia Huck wrote:
> On Thu, 3 Dec 2015 13:00:00 +0800
> Stefan Hajnoczi wrote:
>
> > From: Fam Zheng
> >
> > The assertion problem was noticed in 06c3916b35a, but it wasn't
> > completely fixed, because even though the req is not marked as
> > serialising
On 7 December 2015 at 16:27, Cornelia Huck wrote:
> On Mon, 7 Dec 2015 16:50:01 +0100
> Cornelia Huck wrote:
>
>> For x-data-plane=true, we create an iothread automatically for
>> compatibility. Commit d21e877 ("iothread: include id in thread name")
>> exposed that this iothread missed correct p
On 7 December 2015 at 15:55, Markus Armbruster wrote:
> Markus Armbruster (2):
> sdhci: Sanitize "sdhci-pci" properties for future qomification
> sd: Mark brittle abuse of blk_attach_dev() FIXME
>
> hw/sd/sd.c| 1 +
> hw/sd/sdhci.c | 9 +++--
> include/hw/sd/sdhci.h |
On Mon, 7 Dec 2015 16:50:01 +0100
Cornelia Huck wrote:
> For x-data-plane=true, we create an iothread automatically for
> compatibility. Commit d21e877 ("iothread: include id in thread name")
> exposed that this iothread missed correct parenthood: fix this.
>
> Signed-off-by: Cornelia Huck
> -
Add a new scripts/clean-includes, which can be used to automatically
ensure that a C source file includes qemu/osdep.h first and doesn't
then include any headers which osdep.h provides already.
Signed-off-by: Peter Maydell
---
scripts/clean-includes | 109
Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.
This commit was created with scripts/clean-includes.
Signed-off-by: Peter Maydell
---
hw/arm/allwinner-a10.c | 1 +
hw/arm/armv7m.c | 1 +
hw/arm/boot.c| 2 +-
hw/a
We've had some discussion previously (on list and IRC) about adding an
include of "qemu/osdep.h" to everything. The basic idea is that every
.c file should include "qemu/osdep.h" as its first include; then every
other header (and the .c file itself) can rely on the facilities that
osdep.h provides.
Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.
This commit was created with scripts/clean-includes.
Signed-off-by: Peter Maydell
---
target-arm/arm-semi.c | 8 +---
target-arm/cpu.c | 1 +
target-arm/cpu64.c
1 - 100 of 174 matches
Mail list logo
