Public bug reported:
Hello,
I have tried to install CentOs or Fedora27 on my Windows8 using QEMU. I work on
notepad with 4GB.
Unfortunatly, my touchpad nor my usb-mouse are not recognise on the graphical
installation of CentOs and Fedora installation. So, I cannot install them.
Here are the comm
On Tue, Oct 03, 2017 at 11:42:59AM -0300, Eduardo Habkost wrote:
> On Tue, Oct 03, 2017 at 08:14:22PM +1100, David Gibson wrote:
> > pci_bus_is_root() currently relies on a method in the PCIBusClass.
> > But it's always known if a PCI bus is a root bus when we create it, so
> > using a dynamic meth
On Fri, Sep 29, 2017 at 05:16:36PM -0700, Alistair Francis wrote:
> Replace a large number of the fprintf(stderr, "*\n" calls with
> error_report(). The functions were renamed with these commands and then
> compiler issues where manually fixed.
>
> find ./* -type f -exec sed -i \
> 'N;N;N;N;N;
On Tue, Oct 03, 2017 at 05:21:57PM -0500, Michael Roth wrote:
> 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
On Wed, Oct 04, 2017 at 02:32:11PM +1100, Alexey Kardashevskiy wrote:
> 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
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 Hoffmann ,
> > Peter Maydell ,
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
> Acked-by: Alistair Francis
> Signe
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, they can use:
>
> $Q
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 sorte
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 you make the function
[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 o
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 valid CPU options.
> >
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 at 04:07:38PM +0530, Aravinda P
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: Eduardo Habkost
---
vl.c | 5 +
1 file changed, 1 insertion(+),
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
Signed-off-by: Eduardo Habkost
---
Changes v2
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 file
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 /etc/qem
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 r
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 li
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 format
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 out
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 request
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 ('total_sec
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, and
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
Reviewed-by: John Sno
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 same
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
---
v4-v5: no change
v3: rebase to allocation/mapping sen
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 ('num_sectors
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
Reviewed-by: John Sno
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 insertions(+), 6 deletions(-)
diff --git a/block/i
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 diffe
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).
Signed-off-b
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 deletions(-)
diff --git a/qemu-img.c b/qemu-i
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 file
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 c
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
Reviewed-by: John Snow
---
v2-
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
Reviewed-by: John Snow
---
v3-v5: no
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 file
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, we
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 truncation/ove
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 byt
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 d
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 --
qapi/block-c
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 +
3 files changed,
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 blockdev-bac
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 +
tests/qemu-iotests/056.out |
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 ha
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: Stefan Hajnoczi
---
qapi/block-core.json | 5 -
block/io.c |
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 call
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 Hajnoczi
---
qemu-io.c | 15 ---
1 file changed, 12 insertions
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.
A
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 red
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 sho
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.
> P
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
ubuntu@awre
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 ppc-for-2.11, thanks.
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
ubuntu@aw3:/var
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 - 1:2.5+dfsg-5ubuntu
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 ppc-for-2.11.
> ---
>
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 ho
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
>>> ---
>>>
>>> hw/arm/raspi.c | 6 ++
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 a
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
---
hw/vfio/
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 tags/vfio-updates-20171003.
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 cap
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 --git a/hw/arm/xilinx_zynq.c b/hw/arm/xilinx_zy
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:
>
> git rebase -i master -x 'git show | ./scripts
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: A
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 accor
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 | 10 ++
>> hw/arm/xlnx-zynqmp.c | 16
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:
>> >> This patch add a MachineClass element t
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 file changed, 6 insertions(+)
>>
>> diff --git a/h
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 Armbruste
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
>> ---
>> tests/Makefile.inc
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
Signed-off-by: Eduardo Habkost
---
Changes v1
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: Eduardo Habkost
---
vl.c | 5 +
1 file changed, 1 insertion(+),
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
> index 5941c9f751..555db0f258 10
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 +---
> include/hw/arm/xlnx-zynqmp.h | 1 +
> 3 f
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
> >> code to specify a list o
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 are specified the use
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 sup
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 +158,10 @@ static void raspi2
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:
- Use a NULL terminated list
-
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
+++ b/hw/arm/xilinx_zynq.c
@@ -313,6
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: Alis
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 h
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 Bonzini
Suggested-by: Daniel P. Berrange
Signed-off-by:
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 not be correct since q
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
1 - 100 of 246 matches
Mail list logo
