The "stamp file trick" used to group targets of a single multi-output rule
prevents the user from deleting one such target in order to force its
rebuild. Doing so will not touch the stamp file, and therefore only
the dummy ":" command will be executed.
With this patch, ninjatool writes rules that
Build all executables by default except for the known-broken ones.
This also allows running qemu-iotests without manually building
socket_scm_helper.
Reported-by: Max Reitz
Signed-off-by: Paolo Bonzini
---
docs/devel/build-system.rst| 5 +
tests/fp/meson.build | 2 --
tests/m
On 11/09/20 14:42, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> Since the variable is used for path concatenation, the result would
> ignore the prefix directory altogether.
>
> Signed-off-by: Marc-André Lureau
> ---
> meson.build | 5 +
> 1 file changed, 5 insertions(+
On 11/09/20 14:53, Thomas Huth wrote:
> Let's make this file compilable with -Werror=implicit-fallthrough :
> Looking at the code, it seems like the fallthrough is intended here,
> so we should add the corresponding "/* fallthrough */" comment here.
>
> Signed-off-by: Thomas Huth
> ---
> target/
On Thu, 10 Sep 2020 at 09:11, Stefan Hajnoczi wrote:
>
> The following changes since commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a:
>
> Merge remote-tracking branch
> 'remotes/kraxel/tags/sirius/ipxe-20200908-pull-request' into staging
> (2020-09-08 21:21:13 +0100)
>
> are available in the G
On Fri, 11 Sep 2020 12:04:42 +1000
David Gibson wrote:
> On Mon, Sep 07, 2020 at 05:10:46PM +0200, Halil Pasic wrote:
> > On Fri, 24 Jul 2020 12:57:43 +1000
> > David Gibson wrote:
> >
> > > The default behaviour for virtio devices is not to use the platforms
> > > normal
> > > DMA paths, but
On Fri, Sep 11, 2020 at 09:10:18AM +0100, Daniel P. Berrangé wrote:
> On Fri, Sep 11, 2020 at 12:07:27PM +0400, Marc-André Lureau wrote:
> > Hi
> >
> > On Thu, Sep 10, 2020 at 11:50 PM Eduardo Habkost
> > wrote:
> >
> > > Some chardev QOM cleanup patches had to be dropped from my queue
> > > due
Patchew URL: https://patchew.org/QEMU/20200911125301.413081-1-th...@redhat.com/
Hi,
This series failed build test on FreeBSD host. Please find the details below.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that
On 11/09/2020 15.41, Thomas Huth wrote:
> On 10/09/2020 11.36, Collin Walling wrote:
>> As more features and facilities are added to the Read SCP Info (RSCPI)
>> response, more space is required to store them. The space used to store
>> these new features intrudes on the space originally used to st
On 9/11/20 3:42 PM, Paolo Bonzini wrote:
> Fix high-parallelism builds by forcing all generated headers
> to be created before tests are compiled.
>
> Reported-by: Claudio Fontana
> Signed-off-by: Paolo Bonzini
> ---
> tests/meson.build | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-
On Fri, Sep 11, 2020 at 02:22:51PM +0800, Robert Hoo wrote:
> On Wed, 2020-09-09 at 14:15 -0400, Eduardo Habkost wrote:
> > Hi,
> >
> > Thanks for the patch, and sorry for taking so long to review
> > this. I'm finally getting to the patches that were postponed to
> > 5.2.
> >
> > Comments and q
Hi
On Fri, Sep 11, 2020 at 5:08 PM Paolo Bonzini wrote:
> On 11/09/20 12:24, Paolo Bonzini wrote:
> >>
> >> - from_qemu_none(ptr: *const sys::P) -> T
> >> Return a Rust type T for a const ffi pointer P.
> >>
> >> - from_qemu_full(ptr: *mut sys::P) -> T
> >> Return a Rust type T for a ffi poi
Hello,
The fixes are for the bugs found in colo-compare during our testing
and applications.
Please help to review, thanks a lot.
Regards,
Derek Su
Derek Su (2):
colo-compare: Fix incorrect data type conversion
colo-compare: Record packet creation time by QEMU_CLOCK_REALTIME
net/colo-comp
Record packet creation time by QEMU_CLOCK_REALTIME instead of
QEMU_CLOCK_HOST. The time difference between `now` and packet
`creation_ms` has the possibility of an unexpected negative value
and results in wrong comparison after changing the host clock.
Signed-off-by: Derek Su
---
net/colo-compar
Fix data type conversion of compare_timeout. The incorrect
conversion results in a random compare_timeout value and
unexpected stalls in packet comparison.
Signed-off-by: Derek Su
---
net/colo-compare.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/colo-compare.c b
preallocate_co() does not resize the image correctly if the original
size was not cluster-aligned.
This series should be applied on top of Max's block branch (I tested
it with commit 8e66c829eda997dad661d49d73668b1fd3e6043d).
https://git.xanclic.moe/XanClic/qemu/commits/branch/block
Alberto G
This function preallocates metadata structures and then extends the
image to its new size, but that new size calculation is wrong because
it doesn't take into account that the host_offset variable is always
cluster-aligned.
This problem can be reproduced with preallocation=metadata when the
origin
qcow2_alloc_cluster_offset() takes an (unaligned) guest offset and
returns the (aligned) offset of the corresponding cluster in the qcow2
image.
In practice none of the callers need to know where the cluster starts
so this patch makes the function calculate and return the final host
offset directl
On Tue, 25 Aug 2020 at 15:49, Aaron Lindsay
wrote:
>
> This check was backwards when introduced in commit
> 033614c47de78409ad3fb39bb7bd1483b71c6789:
>
> target/arm: Filter cycle counter based on PMCCFILTR_EL0
>
> Signed-off-by: Aaron Lindsay
> ---
> target/arm/helper.c | 2 +-
> 1 file chan
Hi
On Thu, Sep 10, 2020 at 9:49 PM wrote:
>
> Shameful pain point: meson & cargo don't play nicely together.
>
I realize you need to configure with --enable-debug if you try this patch,
or it will fail to find the library location. (eh, it's really a PoC!).
Obviously, tested on a Linux/Fedora w
Back in 2018 we introduced support for killing the whole QEMU process
instead of just one thread, when a seccomp rule is violated:
commit bda08a5764d470f101fa38635d30b41179a313e1
Author: Marc-André Lureau
Date: Wed Aug 22 19:02:48 2018 +0200
seccomp: prefer SCMP_ACT_KILL_PROCESS if a
On 9/11/20 7:28 AM, Paolo Bonzini wrote:
On 11/09/20 12:46, Daniel P. Berrangé wrote:
Do we actually need/want it to be in the same monolithic repo
as qemu, as opposed to a qemu-qapi-rust repo ?
I think QAPI and qemu-ga should be separate repos altogether. QAPI
should be included as a submodu
Hello all,
Recently while conversing with DanPB this point came up
-> https://www.qemu.org/contribute/security-process/
* Currently QEMU security team is a handful of individual contacts which
restricts community participation in dealing with these issues.
* The Onus also lies with the
On 9/11/20 3:42 PM, Paolo Bonzini wrote:
> Fix high-parallelism builds by forcing all generated headers
> to be created before tests are compiled.
FYI I had this problem too (simply building with -j8)
simply adding a new qapi/file.json.
Reviewed-by: Philippe Mathieu-Daudé
>
> Reported-by: Clau
Hi Edgar,
Thanks, I would try to clean this up as per your comments.
Regards,
Sai Pavan
> -Original Message-
> From: Edgar E. Iglesias
> Sent: Friday, September 11, 2020 1:33 PM
> To: Sai Pavan Boddu
> Cc: Peter Maydell ; Markus Armbruster
> ; 'Marc-André Lureau'
> ; Paolo Bonzini ;
>
Public bug reported:
>From my testing it seems that QEMU built against musl libc crashes on
pthread_cancel cancel calls - if the binary is also built with musl
libc.
Minimal sample:
#include
#include
#include
void* threadfunc(void* ignored) {
while (1) {
pause();
Hi Laurent,
On 8/22/20 8:09 PM, Philippe Mathieu-Daudé wrote:
> - Pass const void* buffer
> - Reorder arguments
>
> Supersedes: <20200822150457.1322519-1-f4...@amsat.org>
>
> Philippe Mathieu-Daudé (2):
> util/hexdump: Convert to take a void pointer argument
> util/hexdump: Reorder qemu_hexd
Fabiano Rosas writes:
> The nested KVM code does not yet support HPT guests. Calling the
> KVM_CAP_PPC_ALLOC_HTAB ioctl currently leads to KVM setting the guest
> as HPT and erroneously executing code in L1 that should only run in
> hypervisor mode, leading to an exception in the L1 vcpu thread w
Greg Kurz writes:
> On Fri, 11 Sep 2020 07:30:37 +0200
> Markus Armbruster wrote:
[...]
>> No, the patch is okay as is.
>>
>> Dumbing it down to keep it simple would also be okay.
>>
>
> What about Ari's proposal to add ERRP_GUARD() and check errors
> with "if (*errp)" like we do for void func
Hansni Bu <1895...@bugs.launchpad.net> writes:
>> > No, it's not set by CentOS-7.5.
>> > Does it mean that we just cannot run the ELF in such a case? I've tried
>> > many times, the assert always fails. Maybe, we can blame CentOS-7.5.
>>
>> The trouble is without MAP_FIXED_NOREPLACE we are at th
* Igor Mammedov (imamm...@redhat.com) wrote:
> theses were deprecatedince since 4.0, remove both HMP and QMP variants.
>
> Users should use device_add commnad instead. To get list of
> possible CPUs and options, use 'info hotpluggable-cpus' HMP
> or query-hotpluggable-cpus QMP command.
>
> Signed
On 9/11/20 6:24 AM, Cornelia Huck wrote:
> On Thu, 10 Sep 2020 19:45:01 +0200
> Thomas Huth wrote:
>
>> On 10/09/2020 11.36, Collin Walling wrote:
>>> Rework the SCLP boundary check to account for different SCLP commands
>>> (eventually) allowing different boundary sizes.
>>>
>>> Signed-off-by: C
On 9/11/20 9:54 AM, Thomas Huth wrote:
> On 11/09/2020 15.41, Thomas Huth wrote:
>> On 10/09/2020 11.36, Collin Walling wrote:
>>> As more features and facilities are added to the Read SCP Info (RSCPI)
>>> response, more space is required to store them. The space used to store
>>> these new feature
On 09/11/20 10:34, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (ler...@redhat.com) wrote:
>> +Markus, Dave, Phil
>>
>> On 09/11/20 03:45, McMillan, Erich wrote:
>>> Hi all,
>>>
>>> (this is my first Qemu patch submission, please let me know if my
>>> formatting/content needs to be fixed).
>>> W
On older kernels which don't implement MAP_FIXED_NOREPLACE the kernel
may still fail to give us the address we asked for despite having
already probed the map for a valid hole. Asserting isn't particularly
useful to the user so let us move the check up and expand the
error_report a little to give t
P J P 于2020年9月11日周五 下午8:30写道：
>
> From: Prasad J Pandit
>
> While servicing the OHCI transfer descriptors(TD), OHCI host
> controller derives variables 'start_addr', 'end_addr', 'len'
> etc. from values supplied by the host controller driver.
> Host controller driver may supply values such that u
On Thu, Sep 10, 2020 at 10:34:20PM +0530, Ani Sinha wrote:
> On Sep 5, 2020, 16:05 +0530, Ani Sinha , wrote:
>
> This change adds a new unit test for the global flag
>
> 'acpi-pci-hotplug-with-bridge-support' which is available for cold plugged
> pci
>
> bridges in i440fx. The fl
** Tags added: linux-user
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1895305
Title:
pthread_cancel fails with "RT33" with musl libc
Status in QEMU:
New
Bug description:
From my testing it
On Fri, Sep 11, 2020 at 8:29 PM Michael S. Tsirkin wrote:
>
> On Thu, Sep 10, 2020 at 10:34:20PM +0530, Ani Sinha wrote:
> > On Sep 5, 2020, 16:05 +0530, Ani Sinha , wrote:
> >
> > This change adds a new unit test for the global flag
> >
> > 'acpi-pci-hotplug-with-bridge-support' which is
On Fri, Sep 11, 2020 at 09:32:02AM -0400, Igor Mammedov wrote:
> it's was deprecated since 3.1
>
> Support for invalid topologies is removed, the user must ensure
> that topologies described with -smp include all possible cpus,
> i.e. (sockets * cores * threads) == maxcpus or QEMU will
> exit with
* Laszlo Ersek (ler...@redhat.com) wrote:
> On 09/11/20 10:34, Dr. David Alan Gilbert wrote:
> > * Laszlo Ersek (ler...@redhat.com) wrote:
> >> +Markus, Dave, Phil
> >>
> >> On 09/11/20 03:45, McMillan, Erich wrote:
> >>> Hi all,
> >>>
> >>> (this is my first Qemu patch submission, please let me kn
On 10/09/2020 11.36, Collin Walling wrote:
> DIAGNOSE 0x318 (diag318) is an s390 instruction that allows the storage
> of diagnostic information that is collected by the firmware in the case
> of hardware/firmware service events.
>
> QEMU handles the instruction by storing the info in the CPU stat
On Tue, Sep 01, 2020 at 05:00:17PM +0200, Marc Hartmayer wrote:
> This patch series is about enabling virtio-fs on s390x. For that we need
> + some shim code (first patch), and we need
> + libvhost-user to deal with virtio endiannes for non-legacy virtio
>devices as mandated by the spec.
Con
On Wed, Sep 09, 2020 at 11:20:24AM +0300, Maxim Levitsky wrote:
> On Tue, 2020-09-08 at 16:27 +0100, Stefan Hajnoczi wrote:
> > On Mon, Aug 31, 2020 at 06:01:24PM +0300, Maxim Levitsky wrote:
> > > @@ -460,46 +466,36 @@ static bool
> > > scsi_target_emulate_report_luns(SCSITargetReq *r)
> > >
On 11/09/2020 17.08, Thomas Huth wrote:
> On 10/09/2020 11.36, Collin Walling wrote:
>> DIAGNOSE 0x318 (diag318) is an s390 instruction that allows the storage
>> of diagnostic information that is collected by the firmware in the case
>> of hardware/firmware service events.
>>
>> QEMU handles the i
On 11/09/20 16:00, Marc-André Lureau wrote:
> - from_qemu_none should be a "to_*" or "constructor" conversion (I used
> new_from_foreign)
>
> new_ prefix is not very rusty.
Right, I have changed it to with_foreign so now there is
{as,with,to,into}_foreign, plus unsafe_{from,into}.
These
On 9/11/20 3:31 AM, Max Reitz wrote:
On 09.09.20 14:33, Eric Blake wrote:
If you have the chain 'base.qcow2 <- top.qcow2' and want to merge a
bitmap from top into base, qemu-img was failing with:
qemu-img: Could not open 'top.qcow2': Could not open backing file: Failed to get shared
"write" lo
Hi Dave, and Laszlo,
I'm not exactly following your email '>' formatting on this discussion so
apologies if I've messed it up.
From: Dr. David Alan Gilbert
Sent: Friday, September 11, 2020 10:06 AM
To: Laszlo Ersek
Cc: McMillan, Erich ; qemu-devel@nongnu.org
Vladimir Sementsov-Ogievskiy writes:
> 11.09.2020 14:21, Greg Kurz wrote:
>> On Fri, 11 Sep 2020 13:18:32 +0300
>> Vladimir Sementsov-Ogievskiy wrote:
>>
>>> 11.09.2020 12:38, Greg Kurz wrote:
s/startus/status
On Wed, 9 Sep 2020 21:59:27 +0300
Vladimir Sementsov-Ogievskiy
On Fri, Sep 11, 2020 at 04:06:02PM +0100, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (ler...@redhat.com) wrote:
> > On 09/11/20 10:34, Dr. David Alan Gilbert wrote:
> > > it doesn't have any pretty graphics
> > > or snazzy stuff,
> >
> > Which is arguably completely superfluous on every possi
Public bug reported:
Hello,
One more bug in sd ...
cat << EOF | ./qemu-system-i386 -nodefaults \
-device sdhci-pci,sd-spec-version=3 \
-device sd-card,drive=mydrive \
-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \
-nographic -qtest stdio -m 64m -trace 'sd*'
outl 0xcf8 0x80001003
out
P J P 于2020年9月11日周五 下午10:21写道：
>
>Hello all,
>
> Recently while conversing with DanPB this point came up
>
> -> https://www.qemu.org/contribute/security-process/
>
> * Currently QEMU security team is a handful of individual contacts which
>restricts community participation in dealing w
On 31/07/20 00:11, Sunil Muthuswamy wrote:
> Newer versions of WHPX provide the capability to query the tsc
> and apic frequency. Expose these through the vmware cpuid leaf.
> This patch doesnt support setting the tsc frequency; that will
> come as a separate fix.
>
> Signed-off-by: Sunil Muthuswa
On 01/09/20 01:32, Sunil Muthuswamy wrote:
> Can I please get some eyes on this?
Yes, sorry about the bad timing (5.1 freeze + Meson conversion +
parental leave).
Paolo
>> -Original Message-
>> From: Sunil Muthuswamy
>> Sent: Thursday, July 30, 2020 3:11 PM
>> To: Paolo Bonzini ; Richard
Hi Prasad,
A couple questions:
* I'm guessing this will be a closed list with some application/vetting
procedure for the participants? (Maybe this is what you mean by
"moderated" ?)
* How will the communication be encrypted?
* Will secalert still be subscribed (for managing CVE ID assignme
On Fri, Sep 11, 2020 at 07:50:24PM +0530, P J P wrote:
> Hello all,
>
> Recently while conversing with DanPB this point came up
>
>-> https://www.qemu.org/contribute/security-process/
>
> * Currently QEMU security team is a handful of individual contacts which
> restricts community parti
On Fri, 11 Sep 2020 at 15:22, P J P wrote:
> Proposal: (to address above limitations)
> =
>
> * We set up a new 'qemu-security' mailing list.
>
> * QEMU security issues are reported to this new list only.
>
> * Representatives from various communities subscribe to this list. (List maybe
>
Le 22/08/2020 à 20:09, Philippe Mathieu-Daudé a écrit :
> qemu_hexdump()'s pointer to the buffer and length of the
> buffer are closely related arguments but are widely separated
> in the argument list order (also, the format of
> function prototypes is usually to have the FILE* argument
> coming
On Thu, Sep 10, 2020 at 12:19:19AM +0530, Ani Sinha wrote:
> On Sep 10, 2020, 00:00 +0530, Ani Sinha , wrote:
>
> On Sep 9, 2020, 23:20 +0530, Julia Suvorova , wrote:
>
> On Fri, Sep 4, 2020 at 6:10 PM Ani Sinha wrote:
>
>
>
> Cold plugged bridges are not hot unpluggab
Le 11/09/2020 à 16:35, Philippe Mathieu-Daudé a écrit :
> Hi Laurent,
>
> On 8/22/20 8:09 PM, Philippe Mathieu-Daudé wrote:
>> - Pass const void* buffer
>> - Reorder arguments
>>
>> Supersedes: <20200822150457.1322519-1-f4...@amsat.org>
>>
>> Philippe Mathieu-Daudé (2):
>> util/hexdump: Convert
Le 22/08/2020 à 20:09, Philippe Mathieu-Daudé a écrit :
> Most uses of qemu_hexdump() do not take an array of char
> as input, forcing use of cast. Since we can use this
> helper to dump any kind of buffer, use a pointer to void
> argument instead.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
On 09/11/20 17:06, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (ler...@redhat.com) wrote:
>> On 09/11/20 10:34, Dr. David Alan Gilbert wrote:
>>> I'm missing what this constant exists for - why is the
>>> check there at all Is there something else that lives below this
>>> address that we have
And I forgot to mention that I think it is a great idea :) . Over the past
couple months, I reported a few dozen bugs on launchpad. Even though
many of them are memory-corruptions and might fall under the
"security-bug" label, they could be fixed faster simply because the
reports can reach the main
On Fri, Sep 11, 2020 at 9:22 PM Michael S. Tsirkin wrote:
>
> On Thu, Sep 10, 2020 at 12:19:19AM +0530, Ani Sinha wrote:
> > On Sep 10, 2020, 00:00 +0530, Ani Sinha , wrote:
> >
> > On Sep 9, 2020, 23:20 +0530, Julia Suvorova , wrote:
> >
> > On Fri, Sep 4, 2020 at 6:10 PM Ani Sinha w
On 09/11/20 17:23, Daniel P. Berrangé wrote:
> I don't see why we should have this as a hard coded
> limit that is not runtime configurable.
>
> IOW, why can't we keep our current default and provide a machine type
> property "firmware_max_size" which users can opt-in to setting if
> their partic
I am not sure why, but the expected files did not match for me.
I dropped these for now:
tests/acpi: add a new ACPI table in order to test root pci hotplug on/off
tests/acpi: add a new unit test to test hotplug off/on feature on the root pci
bus
tests/acpi: document addition of table DSDT.root
On Fri, Sep 11, 2020 at 09:35:42PM +0530, Ani Sinha wrote:
> On Fri, Sep 11, 2020 at 9:22 PM Michael S. Tsirkin wrote:
> >
> > On Thu, Sep 10, 2020 at 12:19:19AM +0530, Ani Sinha wrote:
> > > On Sep 10, 2020, 00:00 +0530, Ani Sinha , wrote:
> > >
> > > On Sep 9, 2020, 23:20 +0530, Julia Suvoro
On Fri, Sep 11, 2020 at 9:38 PM Michael S. Tsirkin wrote:
>
>
> I am not sure why, but the expected files did not match for me.
>
> I dropped these for now:
>
> tests/acpi: add a new ACPI table in order to test root pci hotplug on/off
> tests/acpi: add a new unit test to test hotplug off/on featur
On 09/11/20 17:22, McMillan, Erich wrote:
> I agree that fw has become the vendor OS, but at this point there's no
> going back.
> Utilizing a virtual platform allows us to greatly increase the security
> of our code,
> could we make this change a Qemu experimental flag, so that fw vendors could
>
On Fri, Sep 11, 2020 at 9:39 PM Michael S. Tsirkin wrote:
>
> On Fri, Sep 11, 2020 at 09:35:42PM +0530, Ani Sinha wrote:
> > On Fri, Sep 11, 2020 at 9:22 PM Michael S. Tsirkin wrote:
> > >
> > > On Thu, Sep 10, 2020 at 12:19:19AM +0530, Ani Sinha wrote:
> > > > On Sep 10, 2020, 00:00 +0530, Ani S
On Fri, Sep 11, 2020 at 9:45 PM Ani Sinha wrote:
>
> On Fri, Sep 11, 2020 at 9:39 PM Michael S. Tsirkin wrote:
> >
> > On Fri, Sep 11, 2020 at 09:35:42PM +0530, Ani Sinha wrote:
> > > On Fri, Sep 11, 2020 at 9:22 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Thu, Sep 10, 2020 at 12:19:1
I can't repro the breakage. What test command line are you running
with? I am using " make check-qtest-x86_64 V=1"
On Fri, Sep 11, 2020 at 9:41 PM Ani Sinha wrote:
>
> On Fri, Sep 11, 2020 at 9:38 PM Michael S. Tsirkin wrote:
> >
> >
> > I am not sure why, but the expected files did not match fo
On Fri, Sep 11, 2020 at 06:06:27PM +0200, Laszlo Ersek wrote:
> On 09/11/20 17:23, Daniel P. Berrangé wrote:
>
> > I don't see why we should have this as a hard coded
> > limit that is not runtime configurable.
> >
> > IOW, why can't we keep our current default and provide a machine type
> > prop
* Laszlo Ersek (ler...@redhat.com) wrote:
> On 09/11/20 17:06, Dr. David Alan Gilbert wrote:
> > * Laszlo Ersek (ler...@redhat.com) wrote:
> >> On 09/11/20 10:34, Dr. David Alan Gilbert wrote:
>
> >>> I'm missing what this constant exists for - why is the
> >>> check there at all Is there somethi
Apologies for taking a while to get around to this,
* Steve Sistare (steven.sist...@oracle.com) wrote:
> Provide the SAVEVM_FOREACH and SAVEVM_FORALL macros to loop over all save
> VM state handlers. The former will filter handlers based on the operation
> in the later patch "savevm: VM handlers
* Steve Sistare (steven.sist...@oracle.com) wrote:
> To enable live reboot, provide the cprsave QMP command and the VMS_REBOOT
> vmstate-saving operation, which saves the state of the virtual machine in a
> simple file.
>
> Syntax:
> {'command':'cprsave', 'data':{'file':'str', 'mode':'str'}}
>
On Fri, Sep 11, 2020 at 12:52:04PM +0100, Dr. David Alan Gilbert wrote:
> Kevin:
> While we're still arguing about details of the last commit; can we get
> the first few commits in - they seem to be generally nice cleanups/error
> handling.
I'm going to try to send a update next week which just
On 09/11/20 18:21, Daniel P. Berrangé wrote:
> If OVMF maintainers want to reject
> feature proposals they have the right to do that regardless of what
> QEMU sets for max image size. As you say earlier, the existing size
> limit is already enourmous compared to what OVMF actually uses, so
> if th
The underlying host may be limiting the number of outstanding DMA
requests for type 1 IOMMU. Determine if this is the case and if
so retrieve the number of outstanding mappings allowed.
Signed-off-by: Matthew Rosato
---
hw/vfio/common.c | 76 ++--
Kernel commit 492855939bdb added a limit to the number of outstanding DMA
requests for a type1 vfio container. However, lazy unmapping in s390 can in
quite a large number of outstanding DMA requests to build up prior to being
purged, potentially the entire guest DMA space. This results in unexpec
Rather than duplicating the same loop in multiple locations,
create a static function to do the work.
Signed-off-by: Matthew Rosato
---
hw/vfio/common.c | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
ind
When an s390 guest is using lazy unmapping, it can result in a very
large number of oustanding DMA requests, far beyond the default
limit configured for vfio. Let's track DMA usage similar to vfio
in the host, and trigger the guest to flush their DMA mappings
before vfio runs out.
Signed-off-by:
On Fri, 11 Sep 2020 08:56:00 +0800
Yan Zhao wrote:
> On Thu, Sep 10, 2020 at 12:02:44PM -0600, Alex Williamson wrote:
> > On Thu, 10 Sep 2020 13:50:11 +0100
> > Sean Mooney wrote:
> >
> > > On Thu, 2020-09-10 at 14:38 +0200, Cornelia Huck wrote:
> > > > On Wed, 9 Sep 2020 10:13:09 +0800
> >
On 09/11/20 18:22, Dr. David Alan Gilbert wrote:
> We have lots of complex hideous changes that I'm never going to use but
> seem reasonable; this is a tiny change that seems perfectly reasonable
> both for open and closed firmware.
> I realise herding OVMF developers is tricky, but that's not a
On 9/11/20 3:41 AM, Peter Maydell wrote:
>> +/* Detect store by reading the instruction at the program counter. */
>> +uint32_t insn = *(uint32_t *)pc;
>> +switch(insn>>29) {
>> +case 0x5:
>> +switch((insn>>26) & 0x7) {
>
> Here we mask to get a 3-bit field...
>
>> +
* Steve Sistare (steven.sist...@oracle.com) wrote:
> Enable HMP access to the cprsave QMP command.
>
> Usage: cprsave
>
> Signed-off-by: Maran Wilson
> Signed-off-by: Steve Sistare
I realise that the current mode is currently only 'reboot' - can you
please give us a clue as to why you've got
* Laszlo Ersek (ler...@redhat.com) wrote:
> On 09/11/20 18:22, Dr. David Alan Gilbert wrote:
>
> > We have lots of complex hideous changes that I'm never going to use but
> > seem reasonable; this is a tiny change that seems perfectly reasonable
> > both for open and closed firmware.
> > I realis
On 09/09/20 20:24, Philippe Mathieu-Daudé wrote:
> Hyper-V is available on 64-bit versions of Windows,
> do not try to build its support on 32-bit versions.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> configure | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/configure b/config
On 10/09/20 07:45, Philippe Mathieu-Daudé wrote:
> Hyper-V is available on 64-bit versions of Windows,
> do not try to build its support on 32-bit versions.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Since v1: Handle MinGW automatic detection (Thomas, Stefan)
> ---
> configure | 5 -
>
* Steven Sistare (steven.sist...@oracle.com) wrote:
> On 7/30/2020 12:14 PM, Eric Blake wrote:
> > On 7/30/20 10:14 AM, Steve Sistare wrote:
> >> Provide the cprload QMP command. The VM is created from the file produced
> >> by the cprsave command. Guest RAM is restored in-place from the shared
On 9/10/20 12:45 AM, Philippe Mathieu-Daudé wrote:
In the subject, s/intent/attempt/
Hyper-V is available on 64-bit versions of Windows,
do not try to build its support on 32-bit versions.
Signed-off-by: Philippe Mathieu-Daudé
---
Since v1: Handle MinGW automatic detection (Thomas, Stefan)
--
On 10/09/20 16:40, Christian Schoenebeck wrote:
> If it turns out to work fine, then maybe I just push a branch of QEMU for Mac
> developers somewhere for a while, as I think it would lower the entry level
> for new developers on Mac tremendously. Apparently there is still more
> changes
> with
11.09.2020 18:22, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
11.09.2020 14:21, Greg Kurz wrote:
On Fri, 11 Sep 2020 13:18:32 +0300
Vladimir Sementsov-Ogievskiy wrote:
11.09.2020 12:38, Greg Kurz wrote:
s/startus/status
On Wed, 9 Sep 2020 21:59:27 +0300
Vladimir Sement
On 9/11/20 6:55 PM, Richard Henderson wrote:
> On 9/11/20 3:41 AM, Peter Maydell wrote:
>>> +/* Detect store by reading the instruction at the program counter. */
>>> +uint32_t insn = *(uint32_t *)pc;
>>> +switch(insn>>29) {
>>> +case 0x5:
>>> +switch((insn>>26) & 0x7) {
>>
On 9/11/20 7:18 PM, Eric Blake wrote:
> On 9/10/20 12:45 AM, Philippe Mathieu-Daudé wrote:
>
> In the subject, s/intent/attempt/
Oops thanks... Paolo can you fix that directly,
or should I repost?
>
>> Hyper-V is available on 64-bit versions of Windows,
>> do not try to build its support on 32-
* Steve Sistare (steven.sist...@oracle.com) wrote:
> Enable HMP access to the cprinfo QMP command.
>
> Usage: cprinfo
>
> Signed-off-by: Steve Sistare
As with Eric's comment on the qemp I don't think you need it;
for HMP alll you really need is something that lists it in the help.
(Also I'd ex
On 09/09/20 11:08, Stefan Hajnoczi wrote:
> The RCU code that Paolo maintains is missing a MAINTAINERS file entry.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> MAINTAINERS | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7d0a5e91e4..50296caac4 100
On Freitag, 11. September 2020 19:19:05 CEST Paolo Bonzini wrote:
> On 10/09/20 16:40, Christian Schoenebeck wrote:
> > If it turns out to work fine, then maybe I just push a branch of QEMU for
> > Mac developers somewhere for a while, as I think it would lower the entry
> > level for new developer
Some of the enum constant names conflict with the QOM type check
macros (SIFIVE_U_OTP, SIFIVE_U_PRCI). This needs to be addressed
to allow us to transform the QOM type check macros into functions
generated by OBJECT_DECLARE_TYPE().
Rename all the constants to SIFIVE_U_DEV_*, to avoid conflicts.
Some of the enum constant names conflict with a QOM type check
macro (SIFIVE_E_PRCI). This needs to be addressed to allow us to
transform the QOM type check macros into functions generated by
OBJECT_DECLARE_TYPE().
Rename all the constants to SIFIVE_E_DEV_*, to avoid conflicts.
Signed-off-by: Ed
101 - 200 of 293 matches
Mail list logo
