> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> On 27/11/2014 10:11, Pavel Dovgaluk wrote:
> > When POLL interrupt request is processed by x86_cpu_exec_interrupt
> > function, as it were
> before,
> > everything is ok, because I ensure that these calls occur at the same
> > moments in
> reco
> From: Artyom Tarasenko [mailto:atar4q...@gmail.com]
> On Wed, Nov 26, 2014 at 11:47 AM, Pavel Dovgaluk
> wrote:
> > That covermail was wrong. Here is the correct one:
> >
> > This set of patches is related to the reverse execution and deterministic
> > replay of qemu execution This implementati
On 2014/11/28 15:29, Markus Armbruster wrote:
> Since this is main(), the "caller" is the OS. And yes, the OS closes
> the -f file descriptor when main() returns, because it closes *all* file
> descriptors. Calling close() before return from main() is pointless,
> unless you check for errors.
>
Ming Lei writes:
> Hi Kevin,
>
> On Wed, Nov 26, 2014 at 10:46 PM, Kevin Wolf wrote:
>> This improves the performance of requests because an ACB doesn't need to
>> be allocated on the heap any more. It also makes the code nicer and
>> smaller.
>
> I am not sure it is good way for linux aio optim
Gonglei writes:
> On 2014/11/27 20:47, Markus Armbruster wrote:
>
>> writes:
>>
>>> From: Gonglei
>>>
>>> Coverity report:
>>> (94) Event open_fn: Returning handle opened by function "proxy_socket(char
>>> const *, uid_t, gid_t)". [details]
>>> (95) Event var_assign: Assigning: "sock" = han
Am 27.11.2014 um 21:18 schrieb Peter Maydell:
> On 27 November 2014 at 20:09, Stefan Weil wrote:
>> *nearly means that there are still warnings for format strings in C++
>> code.
>
> Hmm, do we still have these with the libvixl version we have
> now? If so, could you forward me a copy of them and
On Fri, Nov 28, 2014 at 9:16 AM, Fam Zheng wrote:
On Thu, 11/27 23:13, Michael S. Tsirkin wrote:
On Thu, Nov 27, 2014 at 07:21:35PM +, Stefan Hajnoczi wrote:
> On Thu, Nov 27, 2014 at 4:33 PM, Michael S. Tsirkin
wrote:
> > We leak cpu mappings when 1st s/g is not exactly the
> > he
Am 28.11.2014 um 07:23 schrieb Liviu Ionescu:
>
> On 28 Nov 2014, at 08:20, Stefan Weil wrote:
>
>> Windows dynamic libraries (DLL files) are also loaded from the
>> executable's directory if they exist there. You don't need a special
>> setup to make that work, it's the standard behaviour.
>
>
I meant, does the coroutine will do yield internally when it get
blocked on send(3)?
On Fri, Nov 28, 2014 at 1:50 PM, Iwan Budi Kusnanto wrote:
> Hi all,
>
> I just found about coroutine in Qemu and it looks good for my use case.
> I have a question about this.
> I found this
> "Coroutines are co
Hi all,
I just found about coroutine in Qemu and it looks good for my use case.
I have a question about this.
I found this
"Coroutines are cooperatively scheduled threads of control. There is
no preemption timer that switches between coroutines periodically,
instead switching between coroutines is
On 28 Nov 2014, at 08:20, Stefan Weil wrote:
> Windows dynamic libraries (DLL files) are also loaded from the
> executable's directory if they exist there. You don't need a special
> setup to make that work, it's the standard behaviour.
ok, great! could you send me your build procedure? (and pr
Am 27.11.2014 um 22:38 schrieb Liviu Ionescu:
>
> On 27 Nov 2014, at 23:14, Stefan Weil wrote:
>
>> Do you really need statically linked executables
>
> actually I don't know, my experience with Windows is limited :-(
>
> on OS X, if I distribute a folder containing an executable and a bunch o
>>> On 11/28/2014 at 02:14 AM, in message
, Stefano
Stabellini wrote:
> On Mon, 7 Jul 2014, Chunyan Liu wrote:
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index addacdb..4f1cbd2 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -479,6
On Fri, 2014-11-28 at 09:50 +0800, Zhu Guihua wrote:
> On Thu, 2014-11-27 at 15:48 +0200, Marcel Apfelbaum wrote:
> > On Thu, 2014-11-27 at 13:38 +0100, Igor Mammedov wrote:
> > > On Thu, 27 Nov 2014 13:41:07 +0200
> > > Marcel Apfelbaum wrote:
> > >
> > > > On Thu, 2014-11-27 at 19:35 +0800, Zhu
On (Fri) 28 Nov 2014 [11:50:51], David Gibson wrote:
> On Thu, Nov 27, 2014 at 02:38:42PM +0530, Amit Shah wrote:
> > On (Thu) 27 Nov 2014 [16:48:10], David Gibson wrote:
> > > VirtIO devices now remember which endianness they're operating in in order
> > > to support targets which may have guests
On Fri, Nov 28, 2014 at 12:58 AM, Paolo Bonzini wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 27/11/2014 17:56, Stefan Hajnoczi wrote:
>> I am asking for a one-line if statement to avoid introducing a
>> subtle assumption that would be a pain to debug in the future.
>> It's s
Hi Kevin,
On Wed, Nov 26, 2014 at 10:46 PM, Kevin Wolf wrote:
> This improves the performance of requests because an ACB doesn't need to
> be allocated on the heap any more. It also makes the code nicer and
> smaller.
I am not sure it is good way for linux aio optimization:
- for raw image with
On 2014/11/28 1:20, Paolo Bonzini wrote:
>
> On 27/11/2014 14:00, Gonglei (Arei) wrote:
>>> >>
>>> >> Running a redhat-6.4-64bit (kernel 2.6.32-358.el6.x86_64) or elder guest
>>> >> on
>>> >> qemu-2.1, with kvm enabled and -cpu host, non default cpu-topology and
>>> >> guest
>>> >> numa
>>> >>
Hi Kevin,
On Wed, Nov 26, 2014 at 7:27 PM, Kevin Wolf wrote:
> Am 25.11.2014 um 08:23 hat Ming Lei geschrieben:
>> Previously -EAGAIN is simply ignored for !s->io_q.plugged case,
>> and sometimes it is easy to cause -EIO to VM, such as NVME device.
>>
>> This patch handles -EAGAIN by io queue for
Public bug reported:
qemu ver: 1.5.3-Latest
guest os: window 7 64bit with 2 cpu and ps2 keybord.
problem: Use virt-viwer as client to connect, When input quickly, the
guest and host cpu will high and the input-char will display later. but
when only 1 cpu on the vm, the problem will not displa
On Wed, Nov 26, 2014 at 7:18 PM, Kevin Wolf wrote:
> Am 25.11.2014 um 08:23 hat Ming Lei geschrieben:
>> In the submit path, we can't complete request directly,
>> otherwise "Co-routine re-entered recursively" may be caused,
>> so this patch fixes the issue with below ideas:
>>
>> - for -EAG
On 2014/11/27 20:47, Markus Armbruster wrote:
> writes:
>
>> From: Gonglei
>>
>> Coverity report:
>> (94) Event open_fn: Returning handle opened by function "proxy_socket(char
>> const *, uid_t, gid_t)". [details]
>> (95) Event var_assign: Assigning: "sock" = handle returned from
>> "proxy_
On Thu, 2014-11-27 at 15:48 +0200, Marcel Apfelbaum wrote:
> On Thu, 2014-11-27 at 13:38 +0100, Igor Mammedov wrote:
> > On Thu, 27 Nov 2014 13:41:07 +0200
> > Marcel Apfelbaum wrote:
> >
> > > On Thu, 2014-11-27 at 19:35 +0800, Zhu Guihua wrote:
> > > > On Thu, 2014-11-27 at 13:11 +0200, Marcel
On Thu, Nov 27, 2014 at 02:38:42PM +0530, Amit Shah wrote:
> On (Thu) 27 Nov 2014 [16:48:10], David Gibson wrote:
> > VirtIO devices now remember which endianness they're operating in in order
> > to support targets which may have guests of either endianness, such as
> > powerpc. This endianness s
On Thu, 2014-11-27 at 14:15 +0200, Marcel Apfelbaum wrote:
> On Thu, 2014-11-27 at 20:08 +0800, Zhu Guihua wrote:
> > On Thu, 2014-11-27 at 13:41 +0200, Marcel Apfelbaum wrote:
> > > On Thu, 2014-11-27 at 19:35 +0800, Zhu Guihua wrote:
> > > > On Thu, 2014-11-27 at 13:11 +0200, Marcel Apfelbaum wro
On Thu, 11/27 23:13, Michael S. Tsirkin wrote:
> On Thu, Nov 27, 2014 at 07:21:35PM +, Stefan Hajnoczi wrote:
> > On Thu, Nov 27, 2014 at 4:33 PM, Michael S. Tsirkin wrote:
> > > We leak cpu mappings when 1st s/g is not exactly the
> > > header. As we don't set ANY_LAYOUT, we can at this point
On 28 Nov 2014, at 00:04, Peter Maydell wrote:
> ... OSX ... clang ... a bunch of warnings ... I'm hoping we'll be able to
> fix these for 2.3.
ok, thank you,
Liviu
On 27 November 2014 at 23:34, Laszlo Ersek wrote:
> Thanks for the hint, I was actually wondering if some official registry
> existed for the node names and types. So yeah I'll attempt to get it in
> there. (Once I find the docs in question in the kernel :))
Documentation/devicetree is probably a
On 11/28/14 00:28, Peter Maydell wrote:
> On 27 November 2014 at 23:18, Laszlo Ersek wrote:
>> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
>> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
>> board.
>>
>> The mmio register block of fw_cfg is adve
Installing VenHw() device paths with this GUID, for the virtio-mmio
transports that we detect, enables other modules to recognize those
VenHw() nodes. (Note that the actual value doesn't change.)
In addition, to avoid reusing GUIDs in unrelated contexts, detach the
driver's FILE_GUID from its prev
On 27 November 2014 at 23:18, Laszlo Ersek wrote:
> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
> board.
>
> The mmio register block of fw_cfg is advertized in the device tree. As
> base address we
The default value of this PCD (in "IntelFrameworkModulePkg.dec")
identifies the "old shell" from EdkShellBinPkg. Our build includes the
"new" shell from ShellBinPkg/UefiShell/UefiShell.inf; let's specify the
FILE_GUID of that.
Otherwise, no boot option will be generated for the Shell application.
and rebase OvmfPkg's PlatformBdsLib on the standalone library.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
| 3 +--
OvmfPkg/Library/QemuBootOrderLib/QemuBootOrder
We have all the required pieces in place. Let's call
SetBootOrderFromQemu() in PlatformBdsPolicyBehavior().
We disable OFW-to-UEFI device path fragment translation for virtio-pci,
and enable it only virtio-mmio at this time.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: L
In preparation for adding OpenFirmware-to-UEFI translation for "MMIO-like"
OFW device path fragments, let's turn the currently exclusive "PCI-like"
translation into "just one" of the possible translations.
- Rename TranslateOfwNodes() to TranslatePciOfwNodes(), because it is
tightly coupled to "
In the next patch(es) we'll customize the PlatformBdsLib instance used by
ArmVirtualizationQemu.dsc. Let's clone it first verbatim from
ArmPlatformPkg/Library/PlatformIntelBdsLib, changing only its FILE_GUID.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
The OpenFirmware device path nodes that QEMU generates for virtio-mmio
transports contain 64-bit hexadecimal values (16 nibbles) -- the base
addresses of the register blocks. In order to parse them soon,
ParseUnitAddressHexList() must parse UINT64 values.
Call sites need to be adapted, as expected
The TranslateMmioOfwNodes() function recognizes the following OpenFirmware
device paths:
virtio-blk: /virtio-mmio@0a003c00/disk@0,0
virtio-scsi disk: /virtio-mmio@0a003a00/channel@0/disk@2,3
virtio-net NIC: /virtio-mmio@0a003e00/ethernet-phy@0
The new transla
Qemu's firmware configuration interface consists of two MMIO registers, a
16-bit selector and an 8-bit data register. Parse their addresses and
verify their sizes from the DTB, and expose them to the rest of DXE by
storing them in dynamic PCDs.
Contributed-under: TianoCore Contribution Agreement 1
Soon there will be more than one modules (in separate packages) that need
to have an understanding about the GUID used in the VenHw() device path
nodes that describe virtio-mmio transports. Define such a GUID explicitly.
Preserve the current value (which happens to be the FILE_GUID of
ArmPlatformP
fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
board.
The mmio register block of fw_cfg is advertized in the device tree. As
base address we pick 0x0902, which conforms to the comment preceding
"a15
After reviewing OvmfPkg's use of its own QemuFwCfgLib instances, it is
clear that its only pre-DXE fw_cfg dependency concerns S3 support (the
QemuFwCfgS3Enabled() call in "PlatformPei/Platform.c").
For ARM guests, S3 is in the distant future, but we can see several
shorter term applications for fw
In PlatformBdsPolicyBehavior() we should follow the same pattern as in
OvmfPkg's: after the consoles are connected,
- connect all drivers and devices,
- enumerate all boot options,
- enter the Intel BDS FrontPage if the user presses a key different from
Enter.
We set the countdown to 3 seconds,
The series
- adds a DTB- and MMIO-based fw_cfg client library to the
ArmVirtualizationQemu platform (patches #1 and #2),
- makes OvmfPkg's OpenFirmware to UEFI devpath translation logic
reusable for the ArmVirtualizationQemu platform, making the virtio-pci
specific bits conditional (patches
We'll use them in board-specific code in the next patch.
Signed-off-by: Laszlo Ersek
---
include/hw/nvram/fw_cfg.h | 3 +++
hw/nvram/fw_cfg.c | 2 --
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index 56e1ed7..286d94
A number of ARM guest firmware features [1] would like to rely on a
"fw_cfg-like conduit device" [2], so let's add just that.
[1] boot order, ACPI linker/loader, '-kernel' booting, maybe SMBIOS
tables, etc
[2] http://thread.gmane.org/gmane.comp.emulators.qemu/304059/focus=306834
Thanks,
Laszl
Hi,
this message is meant as a short, cross-posted thread starter, so that
both qemu- and edk2-side comments can be kept in one thread. I'll follow
up with two series:
- the first small series for qemu adds fw_cfg to the arm "virt" machine
type in qemu, automatically exposing the "bootorder" fw
On Fri, Nov 28, 2014 at 12:49 AM, Michael S. Tsirkin wrote:
> On Thu, Nov 27, 2014 at 06:00:36PM +0400, Andrey Korolyov wrote:
>> On Thu, Nov 27, 2014 at 3:28 PM, Michael S. Tsirkin wrote:
>> > On Thu, Nov 27, 2014 at 03:50:11PM +0400, Andrey Korolyov wrote:
>> >> On Thu, Nov 27, 2014 at 2:45 PM,
On 27 November 2014 at 20:27, Liviu Ionescu wrote:
> if you are interested, three small warnings when building QEMU on OS X:
I build on OSX fairly often; because it's using clang it still
has a bunch of warnings which happen because clang reports a
different set of things to gcc. I'm hoping we'll
On Thu, Nov 27, 2014 at 06:00:36PM +0400, Andrey Korolyov wrote:
> On Thu, Nov 27, 2014 at 3:28 PM, Michael S. Tsirkin wrote:
> > On Thu, Nov 27, 2014 at 03:50:11PM +0400, Andrey Korolyov wrote:
> >> On Thu, Nov 27, 2014 at 2:45 PM, Denis V. Lunev wrote:
> >> > Excessive virtio_balloon inflation
On 27 Nov 2014, at 23:14, Stefan Weil wrote:
> Do you really need statically linked executables
actually I don't know, my experience with Windows is limited :-(
on OS X, if I distribute a folder containing an executable and a bunch of
dynamic libraries, the folder where the executable is loca
Am 27.11.2014 um 21:52 schrieb Liviu Ionescu:
>
> On 27 Nov 2014, at 22:09, Stefan Weil wrote:
>
>> ... use Mingw-w64. It compiles QEMU ...
>
> one of my requirements for a Windows version of QEMU is to be statically
> linked, and do not depend on third party libraries that are not present in
On Thu, Nov 27, 2014 at 07:21:35PM +, Stefan Hajnoczi wrote:
> On Thu, Nov 27, 2014 at 4:33 PM, Michael S. Tsirkin wrote:
> > We leak cpu mappings when 1st s/g is not exactly the
> > header. As we don't set ANY_LAYOUT, we can at this point
> > simply assert the correct length.
> >
> > This wil
On 27 Nov 2014, at 22:09, Stefan Weil wrote:
> ... use Mingw-w64. It compiles QEMU ...
one of my requirements for a Windows version of QEMU is to be statically
linked, and do not depend on third party libraries that are not present in a
common Windows installation.
do you have a build proced
On 27 Nov 2014, at 22:18, Peter Maydell wrote:
> On 27 November 2014 at 20:09, Stefan Weil wrote:
>> *nearly means that there are still warnings for format strings in C++
>> code.
>
> Hmm, do we still have these with the libvixl version we have
> now? If so, could you forward me a copy of them
On 27 November 2014 at 20:09, Stefan Weil wrote:
> *nearly means that there are still warnings for format strings in C++
> code.
Hmm, do we still have these with the libvixl version we have
now? If so, could you forward me a copy of them and I'll see
if I can persuade upstream to fix them...
tha
On 27 Nov 2014, at 22:09, Stefan Weil wrote:
> There is a better alternative: use Mingw-w64.
working on it.
> Maybe we should drop MinGW support completely...
ok, as soon as we fix the build details on MinGW-w64, I'll remove the MinGW
instructions from my wiki.
Liviu
Am 27.11.2014 um 20:57 schrieb Liviu Ionescu:
>
> On 27 Nov 2014, at 21:34, Peter Maydell wrote:
>
>> On 27 November 2014 at 16:43, Liviu Ionescu wrote:
>>> in qemu-common.h:
>>>
>>> #ifdef _WIN32
>>> #include "sysemu/os-win32.h"
>>> #endif
>>>
>>> #ifdef __MINGW32__
>>> #include "sysemu/os-win
On 27 Nov 2014, at 21:34, Peter Maydell wrote:
> On 27 November 2014 at 16:43, Liviu Ionescu wrote:
>> in qemu-common.h:
>>
>> #ifdef _WIN32
>> #include "sysemu/os-win32.h"
>> #endif
>>
>> #ifdef __MINGW32__
>> #include "sysemu/os-win32.h"
>> #endif
>
> Wait, so your mingw toolchain doesn't
On 27 November 2014 at 16:43, Liviu Ionescu wrote:
> in qemu-common.h:
>
> #ifdef _WIN32
> #include "sysemu/os-win32.h"
> #endif
>
> #ifdef __MINGW32__
> #include "sysemu/os-win32.h"
> #endif
Wait, so your mingw toolchain doesn't define _WIN32 ??
That seems likely to break a lot of other code tha
On Thu, Nov 27, 2014 at 4:33 PM, Michael S. Tsirkin wrote:
> We leak cpu mappings when 1st s/g is not exactly the
> header. As we don't set ANY_LAYOUT, we can at this point
> simply assert the correct length.
>
> This will have to be fixed once ANY_LAYOUT is set.
>
> Signed-off-by: Michael S. Tsir
On 27.11.2014 17:28, Michael Mueller wrote:
The real on-disk size of an image depends on things like the host
filesystem. _img_info already filters it out, use the function in 082.
Signed-off-by: Michael Mueller
---
tests/qemu-iotests/082 | 14 ++---
tests/qemu-iotests/082.out |
On Mon, 7 Jul 2014, Chunyan Liu wrote:
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index addacdb..4f1cbd2 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -479,6 +485,15 @@ static char **
> libxl__build_device_model_args_new(libxl__gc *gc,
> if (b
On 11/27/2014 06:51 PM, Alexander Graf wrote:
>
>
> On 27.11.14 18:34, Eric Auger wrote:
>> On 11/27/2014 06:24 PM, Alexander Graf wrote:
>>>
>>>
>>> On 27.11.14 18:13, Eric Auger wrote:
On 11/27/2014 04:55 PM, Alexander Graf wrote:
>
>
> On 27.11.14 16:28, Alexander Graf wrote:
On 27.11.14 18:34, Eric Auger wrote:
> On 11/27/2014 06:24 PM, Alexander Graf wrote:
>>
>>
>> On 27.11.14 18:13, Eric Auger wrote:
>>> On 11/27/2014 04:55 PM, Alexander Graf wrote:
On 27.11.14 16:28, Alexander Graf wrote:
>
>
> On 27.11.14 16:14, Eric Auger wrote:
>
On Thu, 27 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Nov 27, 2014 10:26 AM, Stefano Stabellini
> wrote:
> >
> > On Thu, 27 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > On Nov 27, 2014 9:58 AM, Stefano Stabellini
> > > wrote:
> > > >
> > > > On Thu, 27 Nov 2014, Konrad Rzeszutek Wilk wrote:
On 27/11/2014 18:45, Markus Armbruster wrote:
>> >
>> > Because no one else calls it directly, it is an internal function. I
>> > want to keep it confined to qemu-timer.c (and possibly cpus.c in the
>> > icount implementation, but maybe not even that is necessary).
> That's a perfectly sensible
On 27/11/2014 10:53, Artyom Tarasenko wrote:
>> >
>> > Deterministic replay has the following features:
>> > * Deterministically replays whole system execution and all contents of
>> > the memory,
>> >state of the hadrware devices, clocks, and screen of the VM.
>> > * Writes execution log
Paolo Bonzini writes:
> On 27/11/2014 10:19, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> Use the external qemu-timer API instead.
>>
>> Ignorant question: why?
>
> Because no one else calls it directly, it is an internal function. I
> want to keep it confined to qemu-timer.c (and
Ekaterina Tumanova writes:
> Move the IOCTL calls that detect logical blocksize from raw_probe_alignment
> into separate function (probe_logical_blocksize).
> Introduce function which detect physical blocksize via IOCTL
> (probe_physical_blocksize).
> Both functions will be used in the next patch
On 11/27/2014 06:24 PM, Alexander Graf wrote:
>
>
> On 27.11.14 18:13, Eric Auger wrote:
>> On 11/27/2014 04:55 PM, Alexander Graf wrote:
>>>
>>>
>>> On 27.11.14 16:28, Alexander Graf wrote:
On 27.11.14 16:14, Eric Auger wrote:
> On 11/27/2014 03:35 PM, Alexander Graf wrote:
>>
On 27.11.14 18:13, Eric Auger wrote:
> On 11/27/2014 04:55 PM, Alexander Graf wrote:
>>
>>
>> On 27.11.14 16:28, Alexander Graf wrote:
>>>
>>>
>>> On 27.11.14 16:14, Eric Auger wrote:
On 11/27/2014 03:35 PM, Alexander Graf wrote:
>
>
> On 27.11.14 15:05, Eric Auger wrote:
>>
On 27/11/2014 17:44, Stefan Hajnoczi wrote:
> On Thu, Nov 27, 2014 at 10:19:45AM +0100, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> Use the external qemu-timer API instead.
>>
>> Ignorant question: why?
>
> Patch seems fine but I concur with Markus. Let's add the rationale to
> th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/11/2014 17:56, Stefan Hajnoczi wrote:
> I am asking for a one-line if statement to avoid introducing a
> subtle assumption that would be a pain to debug in the future.
> It's so easy to add that I'm against merging the patch without this
> prot
On 27/11/2014 14:00, Gonglei (Arei) wrote:
>>
>> Running a redhat-6.4-64bit (kernel 2.6.32-358.el6.x86_64) or elder guest on
>> qemu-2.1, with kvm enabled and -cpu host, non default cpu-topology and guest
>> numa
>> I'm seeing a reliable kernel panic from the guest shortly after boot. It is
>> h
On 11/27/2014 04:55 PM, Alexander Graf wrote:
>
>
> On 27.11.14 16:28, Alexander Graf wrote:
>>
>>
>> On 27.11.14 16:14, Eric Auger wrote:
>>> On 11/27/2014 03:35 PM, Alexander Graf wrote:
On 27.11.14 15:05, Eric Auger wrote:
> On 11/26/2014 03:46 PM, Eric Auger wrote:
>> O
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/11/2014 01:51, Tony Breeds wrote:
> On Wed, Nov 26, 2014 at 03:01:01PM +0100, Paolo Bonzini wrote:
>> Use the external qemu-timer API instead.
>
> Perhaps it's obvious but is it reasonable to expand on why you're
> doign this in the commit me
CCing Riku Voipio for a review.
Paolo
On 23/11/2014 14:28, Wei-cheng, Wang wrote:
> Hi,
>
> This patch adds support for sending AUXV packet.
> This is required for debugging Linux position independent executables.
> Otherwise, gdb client cannot find out where the executable is loaded.
>
> Signe
On Wed, Nov 26, 2014 at 05:15:44PM +0800, Ming Lei wrote:
> On Wed, Nov 26, 2014 at 12:18 AM, Stefan Hajnoczi wrote:
> >>
> >> You mean the abort BH may not have chance to run before its deletion
> >> in the detach callback?
> >
> > Exactly. Any time you schedule a BH you need to be aware of thin
On 27/11/2014 10:11, Pavel Dovgaluk wrote:
> When POLL interrupt request is processed by x86_cpu_exec_interrupt function,
> as it were before,
> everything is ok, because I ensure that these calls occur at the same moments
> in record/replay.
Does this partial revert work?
Paolo
diff --git a
On 27/11/2014 11:15, Peter Lieven wrote:
> vring_map causes a huge overhead by calling memory_region_find everytime.
> the vring_map is executed already on vring_setup and there is also the memory
> region referenced.
>
> Signed-off-by: Peter Lieven
vring_map/unmap is going to disappear and be
On Thu, Nov 27, 2014 at 10:19:45AM +0100, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
> > Use the external qemu-timer API instead.
>
> Ignorant question: why?
Patch seems fine but I concur with Markus. Let's add the rationale to
the commit description.
pgpj67g1P8W4L.pgp
Description: P
On 27/11/2014 13:29, Stefan Hajnoczi wrote:
> +bool bitmap_test_and_clear_atomic(unsigned long *map, long start, long nr)
> +{
> +unsigned long *p = map + BIT_WORD(start);
> +const long size = start + nr;
> +int bits_to_clear = BITS_PER_LONG - (start % BITS_PER_LONG);
> +unsigned
On 26 Nov 2014, at 22:13, Peter Maydell wrote:
> Hmm. We have a workaround already for a similar thing in
> include/sysemu/os-win32.h,
> but that works by declaring a prototype rather than using a #define, and it's
> guarded by defined(_WIN64). I wonder if some of those workarounds in that file
On 27/11/2014 13:29, Stefan Hajnoczi wrote:
> +void bitmap_set_atomic(unsigned long *map, long start, long nr)
> +{
> +unsigned long *p = map + BIT_WORD(start);
> +const long size = start + nr;
> +int bits_to_set = BITS_PER_LONG - (start % BITS_PER_LONG);
> +unsigned long mask_to_
On Thu, Nov 27, 2014 at 02:09:06PM +, Peter Maydell wrote:
> On 27 November 2014 at 12:42, Peter Maydell wrote:
> > On 27 November 2014 at 12:33, Michael S. Tsirkin wrote:
> >> On Thu, Nov 27, 2014 at 06:04:03PM +0800, Jason Wang wrote:
> >>> virtio_net_handle_ctrl() and other functions that
On 27/11/2014 11:27, Peter Lieven wrote:
> +static __thread struct CoRoutinePool {
> +Coroutine *ptrs[POOL_MAX_SIZE];
> +unsigned int size;
> +unsigned int nextfree;
> +} CoPool;
>
The per-thread ring unfortunately didn't work well last time it was
tested. Devices that do not use
On Thu, Nov 27, 2014 at 05:28:42PM +0100, Cornelia Huck wrote:
> On Thu, 27 Nov 2014 18:18:25 +0200
> "Michael S. Tsirkin" wrote:
>
> > On Thu, Nov 27, 2014 at 05:06:51PM +0100, Cornelia Huck wrote:
>
> > > So we should have a per-device callback into the transport layer, say
> > > check_legacy(
On Tue, Nov 25, 2014 at 05:30:02PM -0600, grhookatw...@gmail.com wrote:
> From: Gary R Hook
>
> Modify block_save_iterate() to return positive/zero/negative
> (success/not done/failure) return status. The computation of
> the blocks transferred (an int64_t) exceeds the size of an
> int return val
On 27/11/2014 10:19, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> Use the external qemu-timer API instead.
>
> Ignorant question: why?
Because no one else calls it directly, it is an internal function. I
want to keep it confined to qemu-timer.c (and possibly cpus.c in the
icount imp
On Thu, Nov 27, 2014 at 05:28:42PM +0100, Cornelia Huck wrote:
> On Thu, 27 Nov 2014 18:18:25 +0200
> "Michael S. Tsirkin" wrote:
>
> > On Thu, Nov 27, 2014 at 05:06:51PM +0100, Cornelia Huck wrote:
>
> > > So we should have a per-device callback into the transport layer, say
> > > check_legacy(
We leak cpu mappings when 1st s/g is not exactly the
header. As we don't set ANY_LAYOUT, we can at this point
simply assert the correct length.
This will have to be fixed once ANY_LAYOUT is set.
Signed-off-by: Michael S. Tsirkin
---
Untested: posting for early feedback.
hw/block/virtio-blk.c
On Thu, Nov 27, 2014 at 06:15:31PM +0800, Halsey Pian wrote:
> Recently, I'm writing an interface of wrapper class for QCOW2 in order to
> manage QCOW2 img files conveniently based on our requirements in my current
> project , this wrapper includes functions such as QCOW2 creating, read/write
> and
On Thu, 27 Nov 2014 15:08:07 +0100
Kevin Wolf wrote:
> The real on-disk size of an image depends on things like the host
> filesystem. _img_info already filters it out, use the function in 060.
>
> Signed-off-by: Kevin Wolf
> ---
> tests/qemu-iotests/060 | 2 +-
> tests/qemu-iotests/060
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> The dirty memory bitmap is managed by ram_addr.h and copied to
> migration_bitmap[] periodically during live migration.
>
> Move the code to sync the bitmap to ram_addr.h where related code lives.
Is this sync code going to need to gain a barrier (
On Thu, 27 Nov 2014 18:18:25 +0200
"Michael S. Tsirkin" wrote:
> On Thu, Nov 27, 2014 at 05:06:51PM +0100, Cornelia Huck wrote:
> > So we should have a per-device callback into the transport layer, say
> > check_legacy()?
>
> I would just have 2 masks: legacy_features and features.
But these b
The real on-disk size of an image depends on things like the host
filesystem. _img_info already filters it out, use the function in 082.
Signed-off-by: Michael Mueller
---
tests/qemu-iotests/082 | 14 ++---
tests/qemu-iotests/082.out | 49 +
On Thu, Nov 20, 2014 at 06:06:26PM +0100, Max Reitz wrote:
> @@ -2003,6 +2015,7 @@ static int qcow2_create(const char *filename, QemuOpts
> *opts, Error **errp)
> size_t cluster_size = DEFAULT_CLUSTER_SIZE;
> PreallocMode prealloc;
> int version = 3;
> +int refcount_width = 16,
On Thu, Nov 27, 2014 at 05:06:51PM +0100, Cornelia Huck wrote:
> On Thu, 27 Nov 2014 17:42:11 +0200
> "Michael S. Tsirkin" wrote:
>
> > On Thu, Nov 27, 2014 at 04:31:39PM +0100, Cornelia Huck wrote:
> > > On Thu, 27 Nov 2014 17:24:22 +0200
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > On Thu,
On Thu, 27 Nov 2014 17:42:11 +0200
"Michael S. Tsirkin" wrote:
> On Thu, Nov 27, 2014 at 04:31:39PM +0100, Cornelia Huck wrote:
> > On Thu, 27 Nov 2014 17:24:22 +0200
> > "Michael S. Tsirkin" wrote:
> >
> > > On Thu, Nov 27, 2014 at 04:16:33PM +0100, Cornelia Huck wrote:
> > > > Yet another ver
1 - 100 of 284 matches
Mail list logo
