Christophe de Dinechin writes:
> I started cutting some stuff out.
>
>> On 14 Jan 2020, at 14:04, Markus Armbruster wrote:
>>
>> Prior art:
>>
>>Presentation
>>KVM Forum 2017: Towards a More Expressive and Introspectable QEMU
>>Command Line
>>
Le 14/01/2020 à 22:09, Richard Henderson a écrit :
> The x86_64 abi has a legacy vsyscall page. The kernel folk
> have been trying to deprecate this since at least v3.1, but
>
> (1) We don't implement the vdso that replaces vsyscalls,
> (2) As of v5.5, the vsyscall page is still enabled by
Hi,
> On Jan 14, 2020, at 3:22 PM, Stefan Hajnoczi wrote:
>
> I haven't seen the link to the muser prototype shared on the list yet,
> so I'm taking the liberty of posting it for discussion:
> https://github.com/oracle/qemu/tree/multi-process-qemu-v0.4.1-muser
>
> Great that a lot of the
> -Original Message-
> From: Thomas Huth [mailto:th...@redhat.com]
> Sent: 14 January 2020 17:08
> To: Shameerali Kolothum Thodi ;
> qemu-devel@nongnu.org; imamm...@redhat.com; m...@redhat.com
> Cc: xuwei (O) ; Linuxarm
> Subject: Re: [PATCH] tests: acpi: update path in
On 15/01/2020 04.10, Pan Nengyuan wrote:
>
> On 1/13/2020 10:32 AM, Pan Nengyuan wrote:
>>
>> On 1/12/2020 6:39 PM, Thomas Huth wrote:
[...]
>>> ... and now I had to unqueue the patch again. It is reproducibly causing
>>> one of the gitlab CI pipelines to fail with a timeout, e.g.:
>>>
>>>
Richard Henderson writes:
> We are not short of numbers for EXCP_*. There is no need to confuse things
> by having EXCP_VMEXIT and EXCP_SYSCALL overlap, even though the former is
> only used for system mode and the latter is only used for user mode.
>
> Signed-off-by: Richard Henderson
Thanks a bunch. This clarifies a number of my misconceptions about
how this is currently used. Most notably this one:
> On 15 Jan 2020, at 10:20, Markus Armbruster wrote:
>
>> We don’t want the QAPI to let arbitrary fields of a QOM object
>> be modified, do we?
>
> We already do: QMP command
Richard Henderson writes:
> This is a bit tidier than open-coding the 5 lines necessary
> to initialize the target_siginfo_t. In addition, this zeros
> the remaining bytes of the target_siginfo_t, rather than
> passing in garbage.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Alex
Hi
On Wed, Jan 15, 2020 at 1:21 PM Markus Armbruster wrote:
>
> Christophe de Dinechin writes:
>
> >> To make this worthwhile, we'd have to replace dynamic QOM properties by
> >> static ones when possible. Monumental task.
> >
> > I’m sure you are right, but it’s hard for me to evaluate, given
On Wed, Jan 15, 2020 at 05:25:50PM +0800, Guoheyi wrote:
>
> 在 2020/1/15 14:30, Michael S. Tsirkin 写道:
> > Problem is IASL disassembler still doesn't work on all hosts
> > we want to support. And its output isn't really stable enough
> > to act as a golden master.
> >
> > Until we have a better
On Wed, Jan 15, 2020 at 02:25:35PM +0800, pannengy...@huawei.com wrote:
> From: Pan Nengyuan
>
> Receive/transmit/event vqs forgot to cleanup in vhost_vsock_unrealize. This
> patch save receive/transmit vq pointer in realize() and cleanup vqs
> through those vq pointers in unrealize(). The leak
在 2020/1/15 14:30, Michael S. Tsirkin 写道:
Problem is IASL disassembler still doesn't work on all hosts
we want to support. And its output isn't really stable enough
to act as a golden master.
Until we have a better tool, I propose the contributor just follows all
steps 1-6. The reason they
On Wed, Jan 15, 2020 at 05:25:50PM +0800, Guoheyi wrote:
>
> 在 2020/1/15 14:30, Michael S. Tsirkin 写道:
> > Problem is IASL disassembler still doesn't work on all hosts
> > we want to support. And its output isn't really stable enough
> > to act as a golden master.
> >
> > Until we have a better
On Mon, Jan 13, 2020 at 05:36:44PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Hyperv's synic (that we emulate) is a feature that allows the guest
> to place some magic (4k) pages of RAM anywhere it likes in GPA.
> This confuses vhost's RAM section merging
> On 15 Jan 2020, at 14:01, Alex Bennée wrote:
>
> ... AFAIK the main users of arm linux user
> are compiler test cases for M-profile CPUs.
I confirm, generally unit tests.
But not necessarily, I used QEMU as the main development platform for the
Cortex-M port of µOS++, a C/C++
This is a bit more efficient than having to allocate and free memory
for each item.
The default size (60) is enough for all the existing incompatible
features or the "Unknown incompatible feature" message.
Suggested-by: Philippe Mathieu-Daudé
Signed-off-by: Alberto Garcia
Reviewed-by: Alex
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote:
> Christophe de Dinechin writes:
>
> > Thanks a bunch. This clarifies a number of my misconceptions about
> > how this is currently used. Most notably this one:
> >
> >> On 15 Jan 2020, at 10:20, Markus Armbruster wrote:
> >>
>
This patch adds a new 'coroutine' flag to QMP command definitions that
tells the QMP dispatcher that the command handler is safe to be run in a
coroutine.
Signed-off-by: Kevin Wolf
Reviewed-by: Marc-André Lureau
---
tests/qapi-schema/qapi-schema-test.json | 1 +
docs/devel/qapi-code-gen.txt
In qdev_set_parent_bus(), when changing the parent bus of a
realized device, if the source and destination buses are not in the
same reset state, some adaptations are required. This patch adds
needed call to resettable_change_parent() to make sure a device reset
state stays coherent with its
Replace deprecated qdev_reset_all by resettable_cold_reset_fn for
the ipl registration in the main reset handlers.
This does not impact the behavior for the following reasons:
+ at this point resettable just call the old reset methods of devices
and buses in the same order than qdev/qbus.
+
Ping.
发件人：gengdongjiu
收件人：pbonzini ;gengdongjiu ;mst
;imammedo ;shannon.zhaosl
;peter.maydell ;fam
;rth ;ehabkost
;mtosatti ;xuwei (O)
;Jonathan Cameron ;james.morse
;qemu-devel ;kvm
;qemu-arm
抄 送：zhengxiang (A) ;Linuxarm
时 间：2020-01-08 19:32:33
主题[PATCH v22 0/9] Add ARMv8 RAS
On Wed, Jan 15, 2020 at 02:12:20PM +0100, Auger Eric wrote:
> >> +static void virtio_iommu_report_fault(VirtIOIOMMU *viommu, uint8_t reason,
> >> + int flags, uint32_t endpoint,
> >> + uint64_t address)
> >> +{
[...]
> >>
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
This commit adds support of Resettable interface to buses and devices:
+ ResettableState structure is added in the Bus/Device state
+ Resettable methods are implemented.
+ device/bus_is_in_reset function defined
This commit allows to transition the objects to the new
multi-phase interface without
Hi all,
The purpose of this series is to split the current reset procedure
into multiple phases. This will help to solve some ordering
difficulties we have during reset.
This is a ready to merge version. I've rebased on master and followed
Richard's remarks on v6. All patches have been reviewed
Adds trace events to reset procedure and when updating the parent
bus of a device.
Signed-off-by: Damien Hedde
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Cornelia Huck
---
hw/core/qdev.c | 29 ++---
hw/core/trace-events | 9
This commit defines an interface allowing multi-phase reset. This aims
to solve a problem of the actual single-phase reset (built in
DeviceClass and BusClass): reset behavior is dependent on the order
in which reset handlers are called. In particular doing external
side-effect (like setting an
Provide a temporary device_legacy_reset function doing what
device_reset does to prepare for the transition with Resettable
API.
All occurrence of device_reset in the code tree are also replaced
by device_legacy_reset.
The new resettable API has different prototype and semantics
(resetting child
This commit make use of the resettable API to reset the device being
hotplugged when it is realized. Also it ensures it is put in a reset
state coherent with the parent it is plugged into.
Note that there is a difference in the reset. Instead of resetting
only the hotplugged device, we reset also
Signed-off-by: Damien Hedde
Reviewed-by: Peter Maydell
Reviewed-by: Richard Henderson
---
docs/devel/index.rst | 1 +
docs/devel/reset.rst | 289 +++
2 files changed, 290 insertions(+)
create mode 100644 docs/devel/reset.rst
diff --git
Hi Peter,
On 1/14/20 7:07 PM, Peter Xu wrote:
> On Tue, Jan 14, 2020 at 09:51:59AM +0100, Auger Eric wrote:
>> Hi Peter,
>
> Hi, Eric,
>
> [...]
>
>>>
+{
+VirtIOIOMMUEndpoint *ep;
+
+ep = g_tree_lookup(s->endpoints, GUINT_TO_POINTER(ep_id));
+if (ep) {
On Mon, Jan 13, 2020 at 06:45:21PM +0100, Olaf Hering wrote:
> With commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea a new member
> smbus_no_migration_support was added, and enabled in two places.
> With commit 4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi
> got new elements, which are
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
Le 15/01/2020 à 12:37, Thomas Huth a écrit :
> The i8042 device is part of the chipset of a machine, so it should
> be selected by the machines or chipsets (e.g. SuperIO chipsets),
> and not be enabled by default.
>
> Signed-off-by: Thomas Huth
> ---
> hw/input/Kconfig | 1 -
> hw/isa/Kconfig
On Thu, 19 Dec 2019 14:47:59 +0800
Heyi Guo wrote:
> According to ACPI spec, _ADR should be used for device which is on a
> bus that has a standard enumeration algorithm. It does not make sense
> to have a _ADR object for devices which already have _HID and will be
> enumerated by OSPM.
>
>
Add a function resettable_change_parent() to do the required
plumbing when changing the parent a of Resettable object.
We need to make sure that the reset state of the object remains
coherent with the reset state of the new parent.
We make the 2 following hypothesis:
+ when an object is put in a
Replace deprecated qbus_reset_all by resettable_cold_reset_fn for
the sysbus reset registration.
Apart for the raspi machines, this does not impact the behavior
because:
+ at this point resettable just calls the old reset methods of devices
and buses in the same order as qdev/qbus.
+ resettable
Hi Peter,
On 1/14/20 7:07 PM, Peter Xu wrote:
> On Tue, Jan 14, 2020 at 09:51:59AM +0100, Auger Eric wrote:
>> Hi Peter,
>
> Hi, Eric,
>
> [...]
>
>>>
+{
+VirtIOIOMMUEndpoint *ep;
+
+ep = g_tree_lookup(s->endpoints, GUINT_TO_POINTER(ep_id));
+if (ep) {
Ping?
On 07.01.2020 13:53, Kamil Rytarowski wrote:
> Hello QEMU Community!
>
> Over the past year the NetBSD team has been working hard on a new user-mode
> API
> for our hypervisor that will be released as part of the upcoming NetBSD 9.0.
> This new API adds user-mode capabilities to create
On Wed, 15 Jan 2020 at 01:17, Benjamin Herrenschmidt
wrote:
> On Tue, 2020-01-14 at 09:59 +, Peter Maydell wrote:
> > Note that semihosting is not a "here's a handy QEMU feature"
> > thing. It's an architecture-specific API and ABI, which should
> > be defined somewhere in a standard external
On Tue, Jan 14, 2020 at 04:43:36PM +0100, Max Reitz wrote:
> On 09.01.20 12:10, Stefan Hajnoczi wrote:
> > Add qemu-img measure support in the "luks" block driver.
> >
> > Signed-off-by: Stefan Hajnoczi
> > ---
> > block/crypto.c | 82 ++
> > 1
On 1/15/20 2:56 PM, Alberto Garcia wrote:
This is a bit more efficient than having to allocate and free memory
for each item.
The default size (60) is enough for all the existing incompatible
features or the "Unknown incompatible feature" message.
Suggested-by: Philippe Mathieu-Daudé
On 1/14/20 10:35 PM, Alex Bennée wrote:
Philippe Mathieu-Daudé writes:
On 1/14/20 7:08 PM, Alex Bennée wrote:
Alberto Garcia writes:
This is a bit more efficient than having to allocate and free memory
for each item.
The default size (60) is enough for all the existing incompatible
On 15.01.20 14:40, Stefan Hajnoczi wrote:
> On Tue, Jan 14, 2020 at 04:25:44PM +0100, Max Reitz wrote:
>> On 09.01.20 12:10, Stefan Hajnoczi wrote:
>>> The qcow2 .bdrv_measure() code calculates the crypto payload offset.
>>> This logic really belongs in block/crypto.c where it can be reused by
>>>
Kevin Wolf writes:
> This patch adds a new 'coroutine' flag to QMP command definitions that
> tells the QMP dispatcher that the command handler is safe to be run in a
> coroutine.
>
> Signed-off-by: Kevin Wolf
> Reviewed-by: Marc-André Lureau
> ---
> tests/qapi-schema/qapi-schema-test.json |
On Wed, Jan 15, 2020 at 02:00:22PM +0100, Auger Eric wrote:
> Hi Peter,
>
>
> On 1/14/20 7:07 PM, Peter Xu wrote:
> > On Tue, Jan 14, 2020 at 09:51:59AM +0100, Auger Eric wrote:
> >> Hi Peter,
> >
> > Hi, Eric,
> >
> > [...]
> >
> >>>
> +{
> +VirtIOIOMMUEndpoint *ep;
> +
>
v2:
- fix compile errors on mingw32 host by introducing RAM_ADDR_UFMT [11/86]
- replace "[PATCH 43/86] hppa: drop RAM size fixup" with alternative
patches made by Philippe (which effectively do the same thing but other
way around)
- ppc440: fix crash and add suggested valid RAM
various foo_rambits() hardcode mapping of RAM sizes to RAM feature bits,
which is hard to reuse and repeats over and over.
Convert maps into GLib's hash tables and perform mapping using
common mapping function.
Follow up patch will reuse tables for actually checking ram-size
property.
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
On Wed, Jan 15, 2020 at 11:56:04AM +, Alex Bennée wrote:
>
> Stefan Hajnoczi writes:
>
> > On Tue, Jan 14, 2020 at 12:11:34PM +0100, Thomas Huth wrote:
> >> On 13/01/2020 11.35, Alex Bennée wrote:
> >> > ..and extemporise a little about their state.
> >> >
> >> > Signed-off-by: Alex Bennée
Benjamin Herrenschmidt writes:
> On Tue, 2020-01-14 at 09:51 +, Alex Bennée wrote:
>> > Well, one of the LCA talks wasn't that interesting so I started
>> > doing
>> > it and am almost done :-)
>> >
>> > I'll look at doing something for arm, riscv and ppc and send
>> > patches
>> > once I
block_resize is safe to run in a coroutine, so use it as an example for
the new 'coroutine': true annotation in the QAPI schema.
Signed-off-by: Kevin Wolf
Reviewed-by: Marc-André Lureau
---
qapi/block-core.json | 3 ++-
blockdev.c | 6 +++---
2 files changed, 5 insertions(+), 4
Am 14.01.2020 um 21:41 hat no-re...@patchew.org geschrieben:
> Patchew URL: https://patchew.org/QEMU/20200114182735.5553-1-kw...@redhat.com/
>
> Hi,
>
> This series failed the docker-quick@centos7 build test. Please find the
> testing commands and
> their output below. If you have Docker
On Tue 14 Jan 2020 07:08:04 PM CET, Alex Bennée wrote:
>g_autoptr(GString) features = g_string_sized_new(60);
>
> will save you the clean-up later.
Ok, will send v2 now.
>> +if (features->len > 0) {
>> +g_string_append(features, ", ");
>> +
In case of NUMA there are 2 cases to consider:
1. '-numa node,memdev', the only one that will be available
for 5.0 and newer machine types.
In this case reuse current behavior, with only difference
memdevs are put into MachineState::ram container +
a temporary glue to keep
It was useless to try fixup ram_size and print warning
on guest access to config register to begin with.
Now previous patch made sure that SDMC can not be realized
with invalid RAM size, so there is no case where warning
and not used ram_size fixup could be triggered.
So remove now dead code.
A regression that was introduced, with the refactor to TranslatorOps,
drops two lines that update the PC when single-stepping is being performed.
Fixes: 11ab74b01e0a ("target/m68k: Convert to TranslatorOps")
Reported-by: Lucien Murray-Pitts
Suggested-by: Lucien Murray-Pitts
Suggested-by:
The i8042 device is part of the chipset of a machine, so it should
be selected by the machines or chipsets (e.g. SuperIO chipsets),
and not be enabled by default.
Signed-off-by: Thomas Huth
---
hw/input/Kconfig | 1 -
hw/isa/Kconfig | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff
> From: Vivek Goyal
>
> Caller can set FUSE_WRITE_KILL_PRIV in write_flags. Parse it and pass it
> to the filesystem.
>
> Signed-off-by: Vivek Goyal
> ---
> tools/virtiofsd/fuse_common.h | 6 +-
> tools/virtiofsd/fuse_lowlevel.c | 4 +++-
> 2 files changed, 8 insertions(+), 2
On 15/01/20 12:37, Thomas Huth wrote:
> The i8042 device is part of the chipset of a machine, so it should
> be selected by the machines or chipsets (e.g. SuperIO chipsets),
> and not be enabled by default.
>
> Signed-off-by: Thomas Huth
> ---
> hw/input/Kconfig | 1 -
> hw/isa/Kconfig | 1 +
> -Original Message-
>
> > Linux PCI subsytem has an option resource_alignment that can be
> > applied to either a single device or all devices. Booting with
> > pci=resource_aligment=4096 will align each device to a page. Do you
> > think pciback should force resource_alignment=4096
Daniel P. Berrangé writes:
> On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote:
>> Christophe de Dinechin writes:
>>
>> > Thanks a bunch. This clarifies a number of my misconceptions about
>> > how this is currently used. Most notably this one:
>> >
>> >> On 15 Jan 2020, at
On Wed, Jan 15, 2020 at 2:29 PM Alistair Francis
wrote:
> > -*flags = cpu_mmu_index(env, 0);
> > -if (riscv_cpu_fp_enabled(env)) {
> > -*flags |= TB_FLAGS_MSTATUS_FS;
> > -}
> > +*flags = cpu_mmu_index(env, 0) | (env->mstatus & MSTATUS_FS);
>
> I don't think this is
On 1/15/20 12:46 PM, Laurent Vivier wrote:
Le 15/01/2020 à 12:37, Thomas Huth a écrit :
The i8042 device is part of the chipset of a machine, so it should
be selected by the machines or chipsets (e.g. SuperIO chipsets),
and not be enabled by default.
The sentence "The i8042 device is part of
Allow a machine to opt in for hostmem backend based initial
RAM even if user used old -mem-path/prealloc options by providing
MachineClass::default_ram_id
Follow up patches will incrementally convert machines to new API,
by dropping memory_region_allocate_system_memory() and setting
the new field will be used by boards to get access to main
RAM memory region and will help to save boiler plate in
boards which often add a field or variable just for this
purpose.
Memory region will be equivalent to what currently used
memory_region_allocate_system_memory() is returning apart
On Tue, Jan 14, 2020 at 12:11:34PM +0100, Thomas Huth wrote:
> On 13/01/2020 11.35, Alex Bennée wrote:
> > ..and extemporise a little about their state.
> >
> > Signed-off-by: Alex Bennée
> > ---
> > documentation.md | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> >
> From: Liu Bo
>
> For fuse's queueinfo, both queueinfo array and queueinfos are allocated in
> fv_queue_set_started() but not cleaned up when the daemon process quits.
>
> This fixes the leak in proper places.
>
> Signed-off-by: Liu Bo
> Signed-off-by: Eric Ren
> ---
>
On Mittwoch, 15. Januar 2020 02:28:03 CET Pan Nengyuan wrote:
> >>> diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> >>> index b5a7c03f26..b146387ae2 100644
> >>> --- a/hw/9pfs/virtio-9p-device.c
> >>> +++ b/hw/9pfs/virtio-9p-device.c
> >>> @@ -215,6 +215,7 @@ static void
Christophe de Dinechin writes:
> Thanks a bunch. This clarifies a number of my misconceptions about
> how this is currently used. Most notably this one:
>
>> On 15 Jan 2020, at 10:20, Markus Armbruster wrote:
>>
>>> We don’t want the QAPI to let arbitrary fields of a QOM object
>>> be
Deprecate device_legacy_reset(), qdev_reset_all() and
qbus_reset_all() to be replaced by new functions
device_cold_reset() and bus_cold_reset() which uses resettable API.
Also introduce resettable_cold_reset_fn() which may be used as a
replacement for qdev_reset_all_fn and qbus_reset_all_fn().
Hi Peter,
On 1/14/20 8:04 PM, Peter Xu wrote:
> On Thu, Jan 09, 2020 at 03:43:15PM +0100, Eric Auger wrote:
>> The event queue allows to report asynchronous errors.
>> The translate function now injects faults when relevant.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>>
>> v11 -> v12:
>> -
On Tue, Jan 14, 2020 at 07:27:31PM +0100, Kevin Wolf wrote:
> Some QMP command handlers can block the main loop for a relatively long
> time, for example because they perform some I/O. This is quite nasty.
> Allowing such handlers to run in a coroutine where they can yield (and
> therefore release
On Tue, Jan 14, 2020 at 04:25:44PM +0100, Max Reitz wrote:
> On 09.01.20 12:10, Stefan Hajnoczi wrote:
> > The qcow2 .bdrv_measure() code calculates the crypto payload offset.
> > This logic really belongs in block/crypto.c where it can be reused by
> > other image formats.
> >
> > The "luks"
On Wed, Jan 15, 2020 at 11:01:44AM +, Shameerali Kolothum Thodi wrote:
>
>
> > -Original Message-
> > From: Thomas Huth [mailto:th...@redhat.com]
> > Sent: 14 January 2020 17:08
> > To: Shameerali Kolothum Thodi ;
> > qemu-devel@nongnu.org; imamm...@redhat.com; m...@redhat.com
> >
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
It's supposed that SOC will check if "-m" provided
RAM size is valid by setting "ram-size" property and
then board would read back valid (possibly corrected
value) to map RAM MemoryReging with valid size.
Well it isn't doing so, since check is called only
indirectly from
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.
Signed-off-by: Igor Mammedov
---
CC:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
From: Philippe Mathieu-Daudé
The firmware has to reside in the PDC range. If the Elf file
expects to load it below FIRMWARE_START, it is incorrect,
regardless the RAM size.
Acked-by: Helge Deller
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Signed-off-by: Igor
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
Am 08.01.2020 um 15:31 hat Sergio Lopez geschrieben:
> This patch series includes fixes for various issues related to
> AioContext mismanagement for various blockdev-initiated actions.
>
> It also adds tests for those actions when executed on drives running
> on an IOThread AioContext.
Thanks,
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually
Le 15/01/2020 à 17:18, Arnd Bergmann a écrit :
> On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta wrote:
>>
>> This patch implements functionality of following ioctl:
>>
>> SNDRV_TIMER_IOCTL_TREAD - Setting enhanced time read
>>
>> Sets enhanced time read which is used for reading time with
Le 15/01/2020 à 16:53, Filip Bozuta a écrit :
> This patch implements functionalities of following ioctls:
>
> RTC_IRQP_READ, RTC_IRQP_SET - Getting/Setting IRQ rate
>
> Read and set the frequency for periodic interrupts, for RTCs
> that support periodic interrupts. The periodic
On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta wrote:
>
> This patch implements functionality of following ioctl:
>
> SNDRV_TIMER_IOCTL_TREAD - Setting enhanced time read
>
> Sets enhanced time read which is used for reading time with timestamps
> and events. The third ioctl's argument is a
On 12/12/19 5:38 PM, Dr. David Alan Gilbert (git) wrote:
From: Stefan Hajnoczi
virtiofsd can exceed the default open file descriptor limit easily on
most systems. Take advantage of the fact that it runs as root to raise
the limit.
Signed-off-by: Stefan Hajnoczi
---
Patchew URL:
https://patchew.org/QEMU/1579100861-73692-1-git-send-email-imamm...@redhat.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST
Hi,
On 15/01/2020 18:48, Greg Kurz wrote:
> Migration can potentially race with CAS reboot. If the migration thread
> completes migration after CAS has set spapr->cas_reboot but before the
> mainloop could pick up the reset request and reset the machine, the
> guest is migrated unrebooted and the
1 - 100 of 362 matches
Mail list logo
