On Mon, 10/02 11:52, Programmingkid wrote:
>
> > On Oct 2, 2017, at 6:11 AM, qemu-devel-requ...@gnu.org wrote:
> >
> > Message: 21
> > Date: Mon, 2 Oct 2017 10:56:27 +0100
> > From: "Daniel P. Berrange"
> > To: qemu-devel@nongnu.org
> > Cc: Fam Zheng , Gerd
Eduardo Habkost writes:
> Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we
> have no default config files that would be disabled using
> -nodefconfig. Update documentation and document -nodefconfig as
> deprecated.
>
> Cc: Markus Armbruster
Eduardo Habkost writes:
> In case there were options set in the default config file, print
> a warning so users can update their scripts.
>
> If somebody wants to keep the config file as-is, avoid the
> warning and use a command-line that will work in future QEMU
> versions,
On Tue, 10/03 18:24, Ian Jackson wrote:
> no-re...@patchew.org writes ("Re: [Qemu-devel] [PATCH RFC 0/6] xen:
> xen-domid-restrict improvements"):
> > This series seems to have some coding style problems. See output below for
> > more information:
>
> Thanks for this automatic mail. I have
On Tue, 10/03 21:22, Eric Blake wrote:
> On 10/03/2017 09:16 PM, no-re...@patchew.org wrote:
> > Hi,
> >
> > This series failed automatic build test. Please find the testing commands
> > and
> > their output below. If you have docker installed, you can probably
> > reproduce it
> > locally.
> >
Eduardo Habkost writes:
> On Mon, Oct 02, 2017 at 02:50:07PM +0200, Paolo Bonzini wrote:
>> On 29/09/2017 21:31, Eduardo Habkost wrote:
>> >> -void DMA_init(ISABus *bus, int high_page_enable)
>> >> +void DMA_init(ISABus *bus, int high_page_enable, Error **errp)
>> >
>> > If
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1352179
Title:
could not
On Tue, Oct 03, 2017 at 07:18:44PM -0300, Philippe Mathieu-Daudé wrote:
> On 10/03/2017 06:36 PM, Alistair Francis wrote:
> > On Tue, Oct 3, 2017 at 1:39 PM, Eduardo Habkost wrote:
> >> On Tue, Oct 03, 2017 at 01:05:18PM -0700, Alistair Francis wrote:
> >>> List all possible
On Tue, Oct 03, 2017 at 02:41:17PM -0700, Alistair Francis wrote:
> On Tue, Oct 3, 2017 at 1:36 PM, Eduardo Habkost wrote:
> > On Tue, Oct 03, 2017 at 01:05:13PM -0700, Alistair Francis wrote:
> >> List all possible valid CPU options.
> >>
> >> Signed-off-by: Alistair Francis
On 03/10/17 20:12, Alexey Kardashevskiy wrote:
> On 03/10/17 17:07, David Gibson wrote:
>> On Mon, Oct 02, 2017 at 02:02:19PM +1100, Alexey Kardashevskiy wrote:
>>> On 29/09/17 21:52, Nikunj A Dadhania wrote:
David Gibson writes:
> On Thu, Sep 28, 2017
Both -nodefconfig and -no-user-config options do the same thing
today, we only need one variable to keep track of them.
Suggested-by: Markus Armbruster
Acked-by: Alistair Francis
Reviewed-by: Markus Armbruster
Signed-off-by:
Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we
have no default config files that would be disabled using
-nodefconfig. Update documentation and document -nodefconfig as
deprecated.
Cc: Markus Armbruster
Acked-by: Alistair Francis
Changes v2 -> v3:
* Move documentation to the right section of qemu-doc.texi
Changes v1 -> v2:
* Document at "Deprecated features" section in qemu-doc.texi
(Daniel)
* Remove documentation for the option from qemu-options.hx
(Markus)
Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf
In case there were options set in the default config file, print
a warning so users can update their scripts.
If somebody wants to keep the config file as-is, avoid the
warning and use a command-line that will work in future QEMU
versions, they can use:
$QEMU -no-user-config -readconfig
Change qemu_config_parse() to return the number of config groups
in success and -EINVAL on error. This will allow callers of
qemu_config_parse() to check if something was really loaded from
the config file.
All existing callers of qemu_config_parse() and
qemu_read_config_file() only check if the
This missed v2.9 and v2.10. Let's try again: we can include this
on v2.11, and remove the default config file in QEMU 2.13 or
2.14.
Changes v3 -> v4:
* Use warn_report() instead of error_report("warning: ...")
(Eric Blake)
* Document as a deprecated feature in qemu-doc.texi
* Updated Subject
On 10/03/2017 09:16 PM, no-re...@patchew.org wrote:
> Hi,
>
> This series failed automatic build test. Please find the testing commands and
> their output below. If you have docker installed, you can probably reproduce
> it
> locally.
>
> 195 [not run] not suitable for this image
Any device that has request_alignment greater than 512 should be
unable to report status at a finer granularity; it may also be
simpler for such devices to be guaranteed that the block layer
has rounded things out to the granularity boundary (the way the
block layer already rounds all other I/O
Previously, the alloc command required that input parameters be
sector-aligned and clamped to 32 bits, because the underlying
bdrv_is_allocated used a 32-bit parameter and asserted aligned
inputs. But now that we have fixed block status to report a
64-bit bytes value, and to properly round
In the continuing quest to make more things byte-based, change
the internal iteration of img_compare(). We can finally drop the
TODO assertions added earlier, now that the entire algorithm is
byte-based and no longer has to shift from bytes to sectors.
Most of the change is mechanical
During 'qemu-img compare', when we are checking that an allocated
portion of one file is all zeros, we don't need to waste time
computing how many additional sectors after the first non-zero
byte are also non-zero. Create a new helper find_nonzero() to do
the check for a first non-zero sector,
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Convert another internal
type (no semantic change), and rename it to match the corresponding
public function rename.
Signed-off-by: Eric Blake
Reviewed-by: Fam Zheng
In the continuing quest to make more things byte-based, change
compare_sectors(), renaming it to compare_buffers() in the
process. Note that one caller (qemu-img compare) only cares
about the first difference, while the other (qemu-img rebase)
cares about how many consecutive sectors have the
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Convert another internal
function (no semantic change).
Signed-off-by: Eric Blake
Reviewed-by: Fam Zheng
Reviewed-by: John Snow
If a read error is encountered during 'qemu-img compare', we
were printing the "Error while reading offset ..." message twice;
this was because our helper function was awkward, printing output
on some but not all paths. Fix it to consistently report errors
on all paths, so that the callers do not
In the continuing quest to make more things byte-based, change
the internal iteration of img_rebase(). We can finally drop the
TODO assertion added earlier, now that the entire algorithm is
byte-based and no longer has to shift from bytes to sectors.
Most of the change is mechanical
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Convert another internal
type (no semantic change), and rename it to match the corresponding
public function rename.
Signed-off-by: Eric Blake
Reviewed-by: Fam Zheng
Now that bdrv_is_allocated accepts non-aligned inputs, we can
remove the TODO added in commit d6a644bb.
Signed-off-by: Eric Blake
Reviewed-by: John Snow
---
v4-v5: no change
v3: new patch [Kevin]
---
block/io.c | 8 ++--
1 file changed, 2
Compare the following images with all-zero contents:
$ truncate --size 1M A
$ qemu-img create -f qcow2 -o preallocation=off B 1G
$ qemu-img create -f qcow2 -o preallocation=metadata C 1G
On my machine, the difference is noticeable for pre-patch speeds,
with more than an order of magnitude in
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Change the internal
loop iteration of zeroing a device to track by bytes instead of
sectors (although we are still guaranteed that we iterate by steps
that are sector-aligned).
We are gradually moving away from sector-based interfaces, towards
byte-based. In the common case, allocation is unlikely to ever use
values that are not naturally sector-aligned, but it is possible
that byte-based values will let us be more precise about allocation
at the end of an unaligned
Continue on the quest to make more things byte-based instead of
sector-based.
Signed-off-by: Eric Blake
Reviewed-by: John Snow
---
v4-v5: no change
v3: new patch
---
qemu-img.c | 27 +++
1 file changed, 15 insertions(+), 12
As long as we are querying the status for a chunk smaller than
the known image size, we are guaranteed that a successful return
will have set pnum to a non-zero size (pnum is zero only for
queries beyond the end of the file). Use that to slightly
simplify the calculation of the current chunk size
Not all callers care about which BDS owns the mapping for a given
range of the file. This patch merely simplifies the callers by
consolidating the logic in the common call point, while guaranteeing
a non-NULL file to all the driver callbacks, for no semantic change.
The only caller that does not
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Continue by converting
an internal function (no semantic change), and simplifying its
caller accordingly.
Signed-off-by: Eric Blake
Reviewed-by: Fam Zheng
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Convert another internal
function (no semantic change), and rename it to is_zero() in the
process.
Signed-off-by: Eric Blake
Reviewed-by: Fam Zheng
We are gradually moving away from sector-based interfaces, towards
byte-based. In the common case, allocation is unlikely to ever use
values that are not naturally sector-aligned, but it is possible
that byte-based values will let us be more precise about allocation
at the end of an unaligned
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Convert another internal
function (no semantic change); and as with its public counterpart,
rename to bdrv_co_block_status() to make the compiler enforce that
we catch all uses. For now,
In the process of converting sector-based interfaces to bytes,
I'm finding it easier to represent a byte count as a 64-bit
integer at the block layer (even if we are internally capped
by SIZE_MAX or even INT_MAX for individual transactions, it's
still nicer to not have to worry about
There are patches floating around to add NBD_CMD_BLOCK_STATUS,
but NBD wants to report status on byte granularity (even if the
reporting will probably be naturally aligned to sectors or even
much higher levels). I've therefore started the task of
converting our block status code to report at a
Not all callers care about which BDS owns the mapping for a given
range of the file. In particular, bdrv_is_allocated() cares more
about finding the largest run of allocated data from the guest
perspective, whether or not that data is consecutive from the
host perspective, and whether or not the
For drive-backup and blockdev-backup, expose the persistent
property, having it default to false. There are no universal
creation parameters, so it must be added to each job type that
it makes sense for individually.
Signed-off-by: John Snow
---
blockdev.c | 10
For jobs that have finished (either completed or canceled), allow the
user to dismiss the job's status reports via block-job-reap.
Signed-off-by: John Snow
---
block/trace-events | 1 +
blockdev.c | 14 ++
qapi/block-core.json | 21
For jobs that complete when a monitor isn't looking, there's no way to
tell what the job's final return code was. We need to allow jobs to
remain in the list until queried for reliable management.
V2:
- Added tests!
- Changed property name (Jeff, Paolo)
RFC:
The next version will add tests for
Add a persistent (manually reap) property to block jobs that forces
them to linger in the block job list (visible to QMP queries) until
the user explicitly dismisses them via QMP.
The reap command itself is implemented in the next commit, and the
feature is exposed to drive-backup and
RFC: The error returned by a job creation command when that device
already has a job attached has become misleading; "Someone should
do something about that!"
Signed-off-by: John Snow
---
tests/qemu-iotests/056 | 227 +
Improve our braindead copy-on-read implementation. Pre-patch,
we have multiple issues:
- we create a bounce buffer and perform a write for the entire
request, even if the active image already has 99% of the
clusters occupied, and really only needs to copy-on-read the
remaining 1% of the clusters
Add a test for qcow2 copy-on-read behavior, including exposure
for the just-fixed bugs.
The copy-on-read behavior is always to a qcow2 image, but the
test is careful to allow running with most image protocol/format
combos as the backing file being copied from (luks being the
exception, as it is
Make it possible to inject errors on writes performed during a
read operation due to copy-on-read semantics.
Signed-off-by: Eric Blake
Reviewed-by: Jeff Cody
Reviewed-by: Kevin Wolf
Reviewed-by: John Snow
Reviewed-by:
Handle a 0-length block status request up front, with a uniform
return value claiming the area is not allocated.
Most callers don't pass a length of 0 to bdrv_get_block_status()
and friends; but it definitely happens with a 0-length read when
copy-on-read is enabled. While we could audit all
Make it easier to enable copy-on-read during iotests, by
exposing a new bool option to main and open.
Signed-off-by: Eric Blake
Reviewed-by: Jeff Cody
Reviewed-by: Kevin Wolf
Reviewed-by: John Snow
Reviewed-by: Stefan
During my quest to switch block status to be byte-based, John
forced me to evaluate whether we have a situation during
copy-on-read where we could exceed BDRV_REQUEST_MAX_BYTES [1].
Sure enough, we have a number of pre-existing bugs in the
copy-on-read code. Fix those, along with adding a test.
On Thu, Sep 28, 2017 at 04:08:21PM +0530, Aravinda Prasad wrote:
> Enable the KVM capability KVM_CAP_PPC_FWNMI so that
> the KVM causes guest exit with NMI as exit reason
> when it encounters a machine check exception on the
> address belonging to a guest. Without this capability
> enabled, KVM
On Thu, Sep 28, 2017 at 04:08:31PM +0530, Aravinda Prasad wrote:
> Block VM migration requests until the machine check
> error handling is complete as (i) these errors are
> specific to the source hardware and is irrelevant on
> the target hardware, (ii) these errors cause data
> corruption and
On Thu, Sep 28, 2017 at 04:08:10PM +0530, Aravinda Prasad wrote:
> Memory error such as bit flips that cannot be corrected
> by hardware are passed on to the kernel for handling.
> If the memory address in error belongs to guest then
> the guest kernel is responsible for taking suitable action.
>
On 10/03/2017 01:43 PM, Jeff Cody wrote:
> On Tue, Oct 03, 2017 at 11:59:28AM -0400, John Snow wrote:
>>
>>
>> On 10/03/2017 11:57 AM, Paolo Bonzini wrote:
>>> On 03/10/2017 05:15, John Snow wrote:
For drive-backup and blockdev-backup, expose the manual-cull
property, having it default
Taken from the upgraded hypervisor:
ubuntu@awrep3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$
sudo qemu-system-aarch64 --version
QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-3ubuntu2.3~cloud0)
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
On Tue, Oct 03, 2017 at 12:14:04PM +0200, Thomas Huth wrote:
> We don't have any 460 or 460F CPUs in QEMU, so the init functions
> are just dead code. Let's simply remove them (translate_init.c
> is already big enough without them).
>
> Signed-off-by: Thomas Huth
Applied to
Taken from the upgraded hypervisor
ubuntu@aw3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$ sudo
qemu-system-aarch64 --version
QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-3ubuntu2.3~cloud0)
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
Today I ran some tests and installed a Newton Deployment on arm64, which
we already know works. I upgraded QEMU and Libvirt on one of the
hypervisors from the xenial-updates/ocata cloud-archive.
See attached notes.
Libvirt - 1.3.1-1ubuntu10.14 -> 2.5.0-3ubuntu5.5~cloud0
QEMU -
On Tue, Oct 03, 2017 at 04:13:11PM +0200, Greg Kurz wrote:
> The offset of the root node is guaranteed to be 0.
>
> This doesn't fix anything, it's just trivial cleanup of the two
> remaining places where this was done under hw/ppc.
>
> Signed-off-by: Greg Kurz
Applied to
Quoting Michael Roth (2017-07-26 20:30:52)
> This series was motivated by the discussion in this thread:
>
> https://www.redhat.com/archives/libvir-list/2017-June/msg01370.html
>
> The issue this series addresses is that when libvirt unplugs a VFIO PCI
> device,
> it may attempt to bind the
On 10/03/2017 06:36 PM, Alistair Francis wrote:
> On Tue, Oct 3, 2017 at 1:39 PM, Eduardo Habkost wrote:
>> On Tue, Oct 03, 2017 at 01:05:18PM -0700, Alistair Francis wrote:
>>> List all possible valid CPU options.
>>>
>>> Signed-off-by: Alistair Francis
NVIDIA has defined a specification for creating GPUDirect "cliques",
where devices with the same clique ID support direct peer-to-peer DMA.
When running on bare-metal, tools like NVIDIA's p2pBandwidthLatencyTest
(part of cuda-samples) determine which GPUs can support peer-to-peer
based on chipset
If vfio_add_std_cap() errors then going to out prepends irrelevant
errors for capabilities we haven't attempted to add as we unwind our
recursive stack. Just return error.
Fixes: 7ef165b9a8d9 ("vfio/pci: Pass an error object to vfio_add_capabilities")
Signed-off-by: Alex Williamson
The following changes since commit d147f7e815f97cb477e223586bcb80c316ae10ea:
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
(2017-10-03 16:27:24 +0100)
are available in the git repository at:
git://github.com/awilliam/qemu-vfio.git
If the hypervisor needs to add purely virtual capabilties, give us a
hook through quirks to do that. Note that we determine the maximum
size for a capability based on the physical device, if we insert a
virtual capability, that can change. Therefore if maximum size is
smaller after added virt
On 10/03/2017 05:05 PM, Alistair Francis wrote:
> List all possible valid CPU options.
>
> Signed-off-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
> ---
>
> hw/arm/xilinx_zynq.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff
On Tue, 19 Sep 2017 14:29:33 +0200
Paolo Bonzini wrote:
> From: "Daniel P. Berrange"
>
> Currently before submitting a series, devs should run checkpatch.pl
> across each patch to be submitted. This can be automated using a
> command such as:
>
>
On 10/03/2017 05:05 PM, Alistair Francis wrote:
> List all possible valid CPU options.
>
> Although the board only ever has a Cortex-M3 we mark the Cortex-M4 as
> supported because the Netduino2 Plus supports the Cortex-M4 and the
> Netduino2 Plus is similar to the Netduino2.
>
> Signed-off-by:
Hi everyone,
I am pleased to announce that the QEMU v2.10.1 stable release is now
available:
You can grab the tarball from our download page here:
https://www.qemu.org/download/#source
v2.10.1 is now tagged in the official qemu.git repository,
and the stable-2.10 branch has been updated
Commit c3e5875afc0f ("checkpatch: check trace-events code style")
introduces a regression as reported:
https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg05820.html
Bareword found where operator expected at ./scripts/checkpatch.pl line 1350,
near "s/($hex[.:\/ ])+$hex//gr"
syntax error at
On Tue, Oct 3, 2017 at 1:36 PM, Eduardo Habkost wrote:
> On Tue, Oct 03, 2017 at 01:05:13PM -0700, Alistair Francis wrote:
>> List all possible valid CPU options.
>>
>> Signed-off-by: Alistair Francis
>> ---
>>
>> hw/arm/xlnx-zcu102.c |
On Tue, Oct 3, 2017 at 1:33 PM, Eduardo Habkost wrote:
> On Tue, Oct 03, 2017 at 01:26:53PM -0700, Alistair Francis wrote:
>> On Tue, Oct 3, 2017 at 1:23 PM, Eduardo Habkost wrote:
>> > On Tue, Oct 03, 2017 at 01:05:09PM -0700, Alistair Francis wrote:
>>
On Tue, Oct 3, 2017 at 1:39 PM, Eduardo Habkost wrote:
> On Tue, Oct 03, 2017 at 01:05:18PM -0700, Alistair Francis wrote:
>> List all possible valid CPU options.
>>
>> Signed-off-by: Alistair Francis
>> ---
>>
>> hw/arm/raspi.c | 6 ++
>> 1
On Tue, Oct 03, 2017 at 06:17:30PM -0300, Eduardo Habkost wrote:
> Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we
> have no default config files that would be disabled using
> -nodefconfig. Update documentation and document -nodefconfig as
> deprecated.
>
> Cc: Markus
On 09/29/2017 07:10 AM, Amarnath Valluri wrote:
This change introduces a new TPM backend driver that can communicate with
swtpm(software TPM emulator) using unix domain socket interface. QEMU talks to
TPM emulator using QEMU's socket-based chardev backend device.
Swtpm uses two Unix sockets for
On 2017-10-02 15:34, Markus Armbruster wrote:
> Max Reitz writes:
>
>> Add a new test file (check-qobject.c) for unit tests that concern
>> QObjects as a whole.
>>
>> Its only purpose for now is to test the qobject_is_equal() function.
>>
>> Signed-off-by: Max Reitz
Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we
have no default config files that would be disabled using
-nodefconfig. Update documentation and document -nodefconfig as
deprecated.
Cc: Markus Armbruster
Acked-by: Alistair Francis
Changes v1 -> v2:
* Document at "Deprecated features" section in qemu-doc.texi
(Daniel)
* Remove documentation for the option from qemu-options.hx
(Markus)
Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we
have no default config files that would be disabled using
-nodefconfig.
Both -nodefconfig and -no-user-config options do the same thing
today, we only need one variable to keep track of them.
Suggested-by: Markus Armbruster
Acked-by: Alistair Francis
Reviewed-by: Markus Armbruster
Signed-off-by:
On Tue, Oct 03, 2017 at 01:05:18PM -0700, Alistair Francis wrote:
> List all possible valid CPU options.
>
> Signed-off-by: Alistair Francis
> ---
>
> hw/arm/raspi.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
>
On Tue, Oct 03, 2017 at 01:05:13PM -0700, Alistair Francis wrote:
> List all possible valid CPU options.
>
> Signed-off-by: Alistair Francis
> ---
>
> hw/arm/xlnx-zcu102.c | 10 ++
> hw/arm/xlnx-zynqmp.c | 16 +---
>
On Tue, Oct 03, 2017 at 01:26:53PM -0700, Alistair Francis wrote:
> On Tue, Oct 3, 2017 at 1:23 PM, Eduardo Habkost wrote:
> > On Tue, Oct 03, 2017 at 01:05:09PM -0700, Alistair Francis wrote:
> >> This patch add a MachineClass element that can be set in the machine C
> >>
On Tue, Oct 03, 2017 at 01:05:11PM -0700, Alistair Francis wrote:
> List all possible valid CPU options.
>
> Although the board only ever has a Cortex-M3 we mark the Cortex-M4 as
> supported because the Netduino2 Plus supports the Cortex-M4 and the
> Netduino2 Plus is similar to the Netduino2.
>
On Tue, Oct 3, 2017 at 1:23 PM, Eduardo Habkost wrote:
> On Tue, Oct 03, 2017 at 01:05:09PM -0700, Alistair Francis wrote:
>> This patch add a MachineClass element that can be set in the machine C
>> code to specify a list of supported CPU types. If the supported CPU
>> types
On Tue, Oct 03, 2017 at 01:05:09PM -0700, Alistair Francis wrote:
> This patch add a MachineClass element that can be set in the machine C
> code to specify a list of supported CPU types. If the supported CPU
> types are specified the user enter CPU (by -cpu at runtime) is checked
> against the
List all possible valid CPU options.
Signed-off-by: Alistair Francis
---
hw/arm/raspi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 5941c9f751..555db0f258 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -158,6
List all possible valid CPU options.
Although the board only ever has a Cortex-M3 we mark the Cortex-M4 as
supported because the Netduino2 Plus supports the Cortex-M4 and the
Netduino2 Plus is similar to the Netduino2.
Signed-off-by: Alistair Francis
---
RFC v2:
-
List all possible valid CPU options.
Signed-off-by: Alistair Francis
---
hw/arm/xilinx_zynq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/arm/xilinx_zynq.c b/hw/arm/xilinx_zynq.c
index 1836a4ed45..de1e0bbce1 100644
--- a/hw/arm/xilinx_zynq.c
+++
This patch add a MachineClass element that can be set in the machine C
code to specify a list of supported CPU types. If the supported CPU
types are specified the user enter CPU (by -cpu at runtime) is checked
against the supported types and QEMU exits if they aren't supported.
Signed-off-by:
There are numorous QEMU machines that only have a single or a handful of
valid CPU options. To simplyfy the management of specificying which CPU
is/isn't valid let's create a property that can be set in the machine
init. We can then check to see if the user supplied CPU is in that list
or not.
I
From: Peter Xu
We have object_get_objects_root() to keep user created objects, however
no place for objects that will be used internally. Create such a
container for internal objects.
CC: Andreas Färber
CC: Markus Armbruster
CC: Paolo
From: Peter Xu
So that internal iothread users can explicitly stop one iothread without
destroying it.
Since at it, fix iothread_stop() to allow it to be called multiple
times. Before this patch we may call iothread_stop() more than once on
single iothread, while that may
The following changes since commit d147f7e815f97cb477e223586bcb80c316ae10ea:
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
(2017-10-03 16:27:24 +0100)
are available in the git repository at:
git://github.com/stefanha/qemu.git tags/block-pull-request
for you
From: Peter Xu
When gcontext is used with iothread, the context will be destroyed
during iothread_stop(). That's not good since sometimes we would like
to keep the resources until iothread is destroyed, but we may want to
stop the thread before that point.
Delay the
After iothread is enabled internally inside QEMU with GMainContext, we
may encounter this warning when destroying the iothread:
(qemu-system-x86_64:19925): GLib-CRITICAL **: g_source_remove_poll:
assertion '!SOURCE_DESTROYED (source)' failed
The problem is that g_source_remove_poll() does not
From: Peter Xu
IOThread is a general framework that contains IO loop environment and a
real thread behind. It's also good to be used internally inside qemu.
Provide some helpers for it to create iothreads to be used internally.
Put all the internal used iothreads into the
On Tue, Oct 03, 2017 at 06:46:02PM +0200, Thomas Huth wrote:
> The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement,
> so QEMU crashes when the user tries to device_add + device_del a device
> that does not have a corresponding hotplug controller. This could be
> provoked for a
A previous commit (4e5ee5b21c) broke USB pass-through by introducing
a typo in a configuration variable.
Signed-off-by: Thomas Jansen
1 - 100 of 246 matches
Mail list logo