On 2019/2/22 下午12:22, Michael S. Tsirkin wrote:
On Thu, Feb 21, 2019 at 10:10:08PM -0500, Michael S. Tsirkin wrote:
On Fri, Feb 22, 2019 at 11:04:05AM +0800, Jason Wang wrote:
On 2019/2/22 上午9:35, Michael S. Tsirkin wrote:
On Thu, Feb 21, 2019 at 05:40:22PM +0800, Jason Wang wrote:
On 2019/
23.02.2019 3:06, John Snow wrote:
> Instead of implying a user_locked/busy status, make it explicit.
> Now, bitmaps in use by migration, NBD or backup operations
> are all treated the same way with the same code paths.
>
> Signed-off-by: John Snow
> Reviewed-by: Eric Blake
hmm, you forget my r-b:
I am OK with just checking and complaining.
Linux too solves the problem in this way:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Makefile?id=51193b76bfff5027cf96ba63effae808ad67cca7
A general "shellcheck" pass wouldn't hurt, tho.
Thank you,
Antonio
--
You rece
23.02.2019 3:06, John Snow wrote:
> Check that the bitmap is not in use prior to it checking if it is
> not enabled/recording guest writes. The bitmap being busy was likely
> at the behest of the user, so this error has a greater chance of being
> understood by the user.
>
> Signed-off-by: John Sn
23.02.2019 3:06, John Snow wrote:
> Currently, the enabled predicate means something like:
> "the QAPI status of the bitmap is ACTIVE."
> After this patch, it should mean exclusively:
> "This bitmap is recording guest writes, and is allowed to do so."
>
> In many places, this is how this predicate
about subject: shouldn't it be "against disabled bit" instead?
23.02.2019 3:06, John Snow wrote:
> bdrv_set_dirty_bitmap and bdrv_reset_dirty_bitmap are only used as an
> internal API by the mirror and migration areas of our code. These
> calls modify the bitmap, but do so at the behest of QEMU an
> > Attached patch creates two separate devices. It's just some QOM
> > boilerplate, they still share 95% of the code.
>
> Thanks. Do you want me to merge this and submit a new version or you want to
> fix up after merging my patch or what should we do with this? (I'm not a fan
> of adding a new
23.02.2019 3:06, John Snow wrote:
> "Frozen" was a good description a long time ago, but it isn't adequate now.
> Rename the frozen predicate to has_successor to make the semantics of the
> predicate more clear to outside callers.
>
> In the process, remove some calls to frozen() that no longer se
On 15/02/2019 16:21, David Gibson wrote:
> On Fri, Feb 15, 2019 at 03:34:52PM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 15/02/2019 14:54, David Gibson wrote:
>>> On Fri, Feb 15, 2019 at 02:32:14PM +1100, Alexey Kardashevskiy wrote:
On 15/02/2019 14:24, David Gibson wrote:
>>>
Ping.
On 21.02.2019 03:08, Kamil Rytarowski wrote:
> On 20.02.2019 18:29, Paolo Bonzini wrote:
>> On 20/02/19 12:59, Kamil Rytarowski wrote:
>>> Ping, still valid.
>>
>> Sorry, I missed your email.
>>
>>> On 15.02.2019 00:38, Kamil Rytarowski wrote:
I consider it as fragile hack and certainly
23.02.2019 3:06, John Snow wrote:
> The current API allows us to report a single status, which we've defined as:
>
> Frozen: has a successor, treated as qmp_locked, may or may not be enabled.
> Locked: no successor, qmp_locked. may or may not be enabled.
> Disabled: Not frozen or locked, disabled.
19.02.2019 16:18, Vladimir Sementsov-Ogievskiy wrote:
> 12.02.2019 1:02, Eric Blake wrote:
>> On 2/11/19 6:56 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> Now negotiation is done in coroutine, so to take benefit of it let's
>>> use non-blocking model.
>>>
>>> Note that QIOChannel handle synchronous
Ping?
On 2019/2/15 11:17, Zheng Xiang wrote:
> Hi Paolo,
>
> On 2019/2/15 2:07, Paolo Bonzini wrote:
>> On 14/02/19 13:27, Xiang Zheng wrote:
>>> There is a small window between the twice blk_is_available in
>>> scsi_disk_emulate_command which would cause crash due to the later
>>> assertion if t
On Sat, Feb 23, 2019 at 11:40:57AM -0300, Maxiwell S. Garcia wrote:
> This adds a handler for ibm,get-vpd RTAS calls, allowing pseries
> guest to collect host information. It is disabled by default to
> avoid unwanted information leakage. To enable it, use:
> ‘-M pseries,vpd-export=on’
>
> Only th
Ping?
http://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg03483.html
-Sandra
Ping?
http://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg03167.html
-Sandra
On 2019/2/19 17:02, Gerd Hoffmann wrote:
What happens if you remove "try-alsa" from the configure line?
This issue could be fixed by passing "export QEMU_AUDIO_DRV=none" to
shell env when alsa support form host kernel is unavailable.
On Thu, Feb 21, 2019 at 01:40:51PM -0700, Alex Williamson wrote:
> Hi Yan,
>
> Thanks for working on this!
>
> On Tue, 19 Feb 2019 16:50:54 +0800
> Yan Zhao wrote:
>
> > This patchset enables VFIO devices to have live migration capability.
> > Currently it does not support post-copy phase.
> >
The first one is suggested by Igor Mammedov to provide rule for multiline
code.
The second is a trivial fix to make example code all indented with 4 spaces.
v4:
* one exception case for function
v3:
* fix typo in both changelog and example
v2:
* adjust Patch 1 as suggested by Eric
Wei Yan
We didn't specify the indent rule for multiline code here, which may
mislead users. And in current code, the code use different rules.
Add this rule in CODING_STYLE to make sure this is clear to every one.
Signed-off-by: Wei Yang
Suggested-by: Igor Mammedov
---
v4:
* widths -> width
* ad
All the example code are indented with four spaces except this one.
Fix this by adding four spaces here.
Signed-off-by: Wei Yang
Reviewed-by: Eric Blake
Reviewed-by: Philippe Mathieu-Daudé
---
CODING_STYLE | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/CODING_STYL
On Mon, Feb 25, 2019 at 09:07:08AM +0800, Wei Yang wrote:
>Currently we do device realization like below:
>
> hotplug_handler_pre_plug()
> dc->realize()
> hotplug_handler_plug()
>
>Before we do device realization and plug, we should allocate necessary
>resources and check if memory-hotplug-su
Currently we do device realization like below:
hotplug_handler_pre_plug()
dc->realize()
hotplug_handler_plug()
Before we do device realization and plug, we should allocate necessary
resources and check if memory-hotplug-support property is enabled.
At the piix4 and ich9, the memory-hotp
On Fri, Feb 22, 2019 at 05:13:37PM +, Mark Cave-Ayland wrote:
> On 22/02/2019 05:59, Richard Henderson wrote:
>
> > This requires VSX, not just Altivec, so Power7 or later.
> >
> > Signed-off-by: Richard Henderson
> > ---
> >
> > At present there are no tunables that can avoid the 64-bit el
On Fri, Feb 22, 2019 at 10:53:54AM -0500, Michael S. Tsirkin wrote:
> On Fri, Feb 22, 2019 at 03:47:36PM +, Peter Maydell wrote:
> > On Fri, 22 Feb 2019 at 02:40, Michael S. Tsirkin wrote:
> > >
> > > The following changes since commit
> > > fc3dbb90f2eb069801bfb4cfe9cbc83cf9c5f4a9:
> > >
> >
On Fri, Feb 22, 2019 at 10:08:22AM +0100, Greg Kurz wrote:
> On Thu, 14 Feb 2019 15:39:13 +1100
> David Gibson wrote:
>
> > The virtio-balloon device's verification of the address given to it by the
> > guest has a number of faults:
> > * The addresses here are guest physical addresses, which
On Fri, Feb 22, 2019 at 07:20:14AM +0100, Thomas Huth wrote:
> On 21/02/2019 19.14, Philippe Mathieu-Daudé wrote:
> > On 2/21/19 12:24 PM, Thomas Huth wrote:
> >> Both functions, object_initialize() and object_property_add_child()
> >> increase
> >> the reference counter of the new object, so one
> On Feb 24, 2019, at 14:46, Peter Maydell wrote:
>
> On Sun, 24 Feb 2019 at 19:37, Stephen Checkoway
> wrote:
>> I think that something about adding the tcg_gen_brcond_tl is causing values
>> to become dead and then qemu aborts.
>
> Yep -- all "TCG temporaries" are dead at the end
> of a b
On Sun, 24 Feb 2019 at 19:46, Michael Tokarev
<1817...@bugs.launchpad.net> wrote:
> I think it is better to just disallow building in a path containing
> spaces, -- there are so many packages and other tools that fails in this
> config, might require lots of work to fix this AND to ensure all futur
On Sun, 24 Feb 2019 at 19:37, Stephen Checkoway
wrote:
> I think that something about adding the tcg_gen_brcond_tl is causing values
> to become dead and then qemu aborts.
Yep -- all "TCG temporaries" are dead at the end
of a basic block, and brcond ends a basic block.
Only globals and "local te
I think it is better to just disallow building in a path containing
spaces, -- there are so many packages and other tools that fails in this
config, might require lots of work to fix this AND to ensure all future
changes are still working, and there's an easy workaround
Just my few cents.
--
You
Hi all,
Sorry for the long email. The TL;DR is I'm trying to add x86 segment limit
checks in TCG and my added code is causing qemu to abort during code generation
because some registers have become dead.
I have some x86 firmware that refuses to boot unless a variety of x86 security
mechanisms
On 2/23/19 11:57 PM, Amed Magdy wrote:
> Thank you for your review and feedback, Richard.
> As Eric mentioned, this is the first time contribution. I have been exploring
> Qemu for some time and try to understand main flow, internals, ..etc.
>
>> You cannot manipulate env like this during transla
On Sun, Feb 24, 2019 at 10:21:52AM +, Peter Maydell wrote:
> On Sun, 24 Feb 2019 at 00:34, Michael S. Tsirkin wrote:
> > Peter, can you merge for_upstream now pls? Don't want to spam
> > the list with a trivial change like that ...
>
> Yes, it's on my list, but so are seven other pullreqs;
>
We missed a bug in a recent patch as we were not testing all the
rounding modes for all operations. However enabling all rounding modes
for mulAdd does slow down the already slowest test and doesn't really
buy us much additional coverage so lets allow the default test flags
to be overridden.
Signe
On Sat, 23 Feb 2019 at 23:35, Richard Henderson
wrote:
>
> One great big block comment isn't the best way to document
> the syntax of a language.
>
> Signed-off-by: Richard Henderson
> ---
> MAINTAINERS | 1 +
> docs/decodetree.rst | 156 ++
>
On Sun, 24 Feb 2019 at 00:34, Michael S. Tsirkin wrote:
> Peter, can you merge for_upstream now pls? Don't want to spam
> the list with a trivial change like that ...
Yes, it's on my list, but so are seven other pullreqs;
seems like everybody likes to submit on a Friday, so
sending on a Friday gu
Thank you so much, Eric.
Sorry about this unclear description.
I forgot to fix user name in git configuration before submitting the patch.
Sorry about any inconvenience.
Thanks,
Ahmed
On Sat, 23 Feb 2019 at 23:46, Eric Blake wrote:
> On 2/22/19 10:25 AM, amagdy.af...@gmail.com wrote:
> > From:
On Sun, 24 Feb 2019 at 08:14, Michael S. Tsirkin wrote:
>
> On Sat, Feb 23, 2019 at 09:10:01PM +0800, Yongji Xie wrote:
> > On Fri, 22 Feb 2019 at 22:54, Michael S. Tsirkin wrote:
> > >
> > > On Fri, Feb 22, 2019 at 03:05:23PM +0800, Yongji Xie wrote:
> > > > On Fri, 22 Feb 2019 at 14:21, Michael
39 matches
Mail list logo
