We should use printf format specifier "%u" instead of "%d" for
argument of type "unsigned int".
Reported-by: Euler Robot
Signed-off-by: Alex Chen
---
qemu-keymap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/qemu-keymap.c b/qemu-keymap.c
index 536e8f2385..6797006dda
On 2020/11/10 20:30, Dr. David Alan Gilbert wrote:
> * Chuan Zheng (zhengch...@huawei.com) wrote:
>> Signed-off-by: Chuan Zheng
>> ---
>> migration/multifd.c | 6
>> migration/multifd.h | 4 +++
>> migration/rdma.c| 82
>> +
>> 3
On 2020/11/10 20:11, Dr. David Alan Gilbert wrote:
> * Chuan Zheng (zhengch...@huawei.com) wrote:
>> Create multifd_setup_ops for TxRx thread, no logic change.
>>
>> Signed-off-by: Chuan Zheng
>> ---
>> migration/multifd.c | 44 +++-
>>
We should use printf format specifier "%u" instead of "%d" for
argument of type "unsigned int".
Reported-by: Euler Robot
Signed-off-by: Alex Chen
---
hw/timer/exynos4210_mct.c | 4 ++--
hw/timer/exynos4210_pwm.c | 8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git
Kindly ping.
On 2020/10/30 10:46, AlexChen wrote:
> The result has been checked to be NULL before, it cannot be NULL here,
> so the check is redundant. Remove it.
>
> Reported-by: Euler Robot
> Signed-off-by: AlexChen
> ---
> net/l2tpv3.c | 9 +++--
> 1 file changed, 3 insertions(+), 6
I think i have found it why.
When we create tls client in migration_tls_client_create(), we reference
tioc->master.
As for main migration thread, it will do dereference after
migration_channel_connect in socket_outgoing_migration().
As for non-TLS migration, it will do another reference in
When creating new tls client, the tioc->master will be referenced, we need
dereferenced
it after tls handshake.
Signed-off-by: Chuan Zheng
---
migration/multifd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/migration/multifd.c b/migration/multifd.c
index
When creating new tls client, the tioc->master will be referred, we need unrefer
it after tls handshake.
Signed-off-by: Chuan Zheng
---
migration/multifd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/migration/multifd.c b/migration/multifd.c
index 68b171f..df76a8e
Fix the following error when compiling:
FAILED: libcommon.fa.p/hw_usb_dev-uas.c.o
clang -Ilibcommon.fa.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader
-I/usr/include/libusb-1.0 -I/usr/include/spice-1 -I/usr/include/spice-server
-I/usr/include/cacard -I/usr/include/glib-2.0
This patch allows initializing the primary host bridge as a CXL capable
hostbridge.
Signed-off-by: Ben Widawsky
--
This patch is WIP.
---
hw/arm/virt.c| 1 +
hw/core/machine.c| 26 ++
hw/i386/acpi-build.c | 8 +++-
hw/i386/microvm.c| 1 +
This represents Intel's proposal for how the system firmware can notify
Linux that the CEDT exists and provides a driver attach point. It is not
in the CXL 2.0 specification as of now.
CXL 2.0 specification adds an _HID, ACPI0016, for CXL capable host
bridges, with a _CID of PNP0A08 (PCIe host
Signed-off-by: Ben Widawsky
---
tests/qtest/cxl-test.c | 93 +
tests/qtest/meson.build | 4 ++
2 files changed, 97 insertions(+)
create mode 100644 tests/qtest/cxl-test.c
diff --git a/tests/qtest/cxl-test.c b/tests/qtest/cxl-test.c
new file mode 100644
This adds just enough of a root port implementation to be able to
enumerate root ports (creating the required DVSEC entries). What's not
here yet is the MMIO nor the ability to write some of the DVSEC entries.
This can be added with the qemu commandline by adding a rootport to a
specific CXL host
A device's volatile and persistent memory are known Host Defined Memory
(HDM) regions. The mechanism by which the device is programmed to claim
the addresses associated with those regions is through dedicated logic
known as the HDM decoder. In order to allow the OS to properly program
the HDMs,
The CXL Early Discovery Table is defined in the CXL 2.0 specification as
a way for the OS to get CXL specific information from the system
firmware.
As of CXL 2.0 spec, only 1 sub structure is defined, the CXL Host Bridge
Structure (CHBS) which is primarily useful for telling the OS exactly
where
From: Vishal Verma
Introduce a new UUID for CXL _OSC that only sets CXL related 'Support'
and Control' Dwords, independent of PCI/PCIe Dwords. This is a proposal
and an example AML implementation to demonstrate what such a compat UUID
would look like.
The AML resulting from this change is:
A CXL memory device (AKA Type 3) is a CXL component that contains some
combination of volatile and persistent memory. It also implements the
previously defined mailbox interface as well as the memory device
firmware interface.
The following example will create a 256M device in a 512M window:
This works like adding a typical pxb device, except the name is
'pxb-cxl' instead of 'pxb-pcie'. An example command line would be as
follows:
-device pxb-cxl,id=cxl.0,bus="pcie.0",bus_nr=1
A CXL PXB is backward compatible with PCIe. What this means in practice
is that an operating system that
For all host bridges, reserve MMIO space with _CRS. The MMIO for the
host bridge lives in a magically hard coded space in the system's
physical address space. The standard mechanism to tell the OS about
regions which can't be used for host bridges is _CRS.
Signed-off-by: Ben Widawsky
---
The easiest way to differentiate a CXL bus, and a PCIE bus is using a
flag. A CXL bus, in hardware, is backward compatible with PCIE, and
therefore the code tries pretty hard to keep them in sync as much as
possible.
The other way to implement this would be to try to cast the bus to the
correct
In a bare metal CXL capable system, system firmware will program
physical address ranges on the host. This is done by programming
internal registers that aren't typically known to OS. These address
ranges might be contiguous or interleaved across host bridges.
For a QEMU guest a new construct is
CXL 2.0 specification adds 2 new dwords to the existing _OSC definition
from PCIe. The new dwords are accessed with a new uuid. This
implementation supports what is in the specification.
We are currently in the process of trying to define a new definition for
_OSC. See later work for an
This opens up the possibility for more types of expanders (other than
PCI and PCIe). We'll need this to create a CXL expander.
Signed-off-by: Ben Widawsky
---
hw/pci-bridge/pci_expander_bridge.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git
CXL host bridges themselves may have MMIO. Since host bridges don't have
a BAR they are treated as special for MMIO.
Signed-off-by: Ben Widawsky
--
It's arbitrarily chosen here to pick 0xD000 as the base for the host
bridge MMIO. I'm not sure what the right way to find free space for
Memory devices implement extra capabilities on top of CXL devices. This
adds support for that.
Signed-off-by: Ben Widawsky
---
hw/cxl/cxl-device-utils.c | 48 -
hw/cxl/cxl-mailbox-utils.c | 48 -
Currently, QEMU makes _UID equivalent to the bus number (_BBN). While
there is nothing wrong with doing it this way, CXL spec has a heavy
reliance on _UID to identify host bridges and there is no link to the
bus number. Having a distinct UID solves two problems. The first is it
gets us around the
This is the beginning of implementing mailbox support for CXL 2.0
devices.
Signed-off-by: Ben Widawsky
---
hw/cxl/cxl-device-utils.c | 131
hw/cxl/cxl-mailbox-utils.c | 93 +
hw/cxl/meson.build | 1 +
A CXL 2.0 component is any entity in the CXL topology. All components
have a analogous function in PCIe. Except for the CXL host bridge, all
have a PCIe config space that is accessible via the common PCIe
mechanisms. CXL components are enumerated via DVSEC fields in the
extended PCIe header space.
A CXL device is a type of CXL component. Conceptually, a CXL device
would be a leaf node in a CXL topology. From an emulation perspective,
CXL devices are the most complex and so the actual implementation is
reserved for discrete commits.
This new device type is specifically catered towards the
This implements the CXL device status registers from 8.2.8.3.1 in the
CXL 2.0 specification. It is capability ID 0001h.
Signed-off-by: Ben Widawsky
---
hw/cxl/cxl-device-utils.c | 45 +-
include/hw/cxl/cxl_device.h | 49 -
2
This cleanup will make it easier to add support for CXL to the mix.
Signed-off-by: Ben Widawsky
---
hw/i386/acpi-build.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 4f66642d88..99b3088c9e
A CXL component is a hardware entity that implements CXL component
registers from the CXL 2.0 spec (8.2.3). Currently these represent 3
general types.
1. Host Bridge
2. Ports (root, upstream, downstream)
3. Devices (memory, other)
A CXL component can be conceptually thought of as a PCIe device
This implements all device MMIO up to the first capability .That
includes the CXL Device Capabilities Array Register, as well as all of
the CXL Device Capability Header Registers. The latter are filled in as
they are implemented in the following patches.
Signed-off-by: Ben Widawsky
---
From: Jonathan Cameron
This hasn't yet been added to the linux kernel tree, so for purposes
of this RFC just add it locally.
Signed-off-by: Jonathan Cameron
Signed-off-by: Ben Widawsky
---
include/standard-headers/linux/pci_regs.h | 1 +
1 file changed, 1 insertion(+)
diff --git
Introduce emulation of Compute Express Link 2.0, which was released
today at https://www.computeexpresslink.org/.
I've pushed a branch here: https://gitlab.com/bwidawsk/qemu/-/tree/cxl-2.0
The emulation has been critical to get the Linux enabling started
(https://lore.kernel.org/linux-cxl/), it
** Changed in: qemu
Assignee: (unassigned) => John Snow (jnsnow)
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1874678
Title:
[Feature
On 2020/11/11 3:02, Krish Sadhukhan wrote:
On 11/9/20 5:49 PM, Like Xu wrote:
Hi Krish,
On 2020/11/10 9:23, Krish Sadhukhan wrote:
@@ -1192,7 +1192,7 @@ void vmx_set_host_fs_gs(struct vmcs_host_state
*host, u16 fs_sel, u16 gs_sel,
}
}
-void vmx_prepare_switch_to_guest(struct
> -Original Message-
> From: Kang, Luwei
> Sent: Wednesday, October 14, 2020 4:05 PM
> To: pbonz...@redhat.com; r...@twiddle.net; ehabk...@redhat.com
> Cc: qemu-devel@nongnu.org; Kang, Luwei
> Subject: [PATCH 2/2] i386/cpu: Make the Intel PT LIP feature configurable
>
> The current
In main func, strdup lo.source may fail. So check whether strdup
lo.source return NULL before using it.
Signed-off-by: Haotian Li
Signed-off-by: Zhiqiang Liu
---
tools/virtiofsd/passthrough_ll.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/virtiofsd/passthrough_ll.c
In main func, func lo_map_reserve is called without NULL check.
If reallocing new_elems fails in func lo_map_grow, the func
lo_map_reserve may return NULL. We should check whether
lo_map_reserve returns NULL before using it.
Signed-off-by: Haotian Li
Signed-off-by: Zhiqiang Liu
---
In fuse_bufvec_advance func, calling fuse_bufvec_current func
may return NULL, so we should check whether buf is NULL before
using it.
Signed-off-by: Haotian Li
Signed-off-by: Zhiqiang Liu
---
tools/virtiofsd/buffer.c | 4
1 file changed, 4 insertions(+)
diff --git
Hi,
We find some potential NULL pointer bugs on tools/virtiofsd.
Three patches are made to fix them
Haotian Li (3):
tools/virtiofsd/buffer.c: check whether buf is NULL in
fuse_bufvec_advance func
virtiofsd: check whether lo_map_reserve returns NULL in main func
virtiofsd: check
Hello,
On behalf of the QEMU Team, I'd like to announce the availability of the
second release candidate for the QEMU 5.2 release. This release is meant
for testing purposes and should not be used in a production environment.
http://download.qemu-project.org/qemu-5.2.0-rc1.tar.xz
Alex Bennée writes:
> Hi,
>
> This collects together a bunch of fixes for 5.2:
Doh, subject did not match body, I of course mean for the current
release candidate.
> - a few resource leak fixes for plugins
> - Xen on arm64 build fixes (from my larger Xen series)
> - a couple of build
On Tue, 10 Nov 2020 at 11:35, Paolo Bonzini wrote:
>
> The following changes since commit 3493c36f0371777c62d1d72b205b0eb6117e2156:
>
> Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20201106' into
> staging (2020-11-06 13:43:28 +)
>
> are available in the Git repository at:
>
>
From: Peter Maydell
Instead of casting an address within a uint8_t array to a
uint32_t*, use stl_le_p(). This handles possibly misaligned
addresses which would otherwise crash on some hosts.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Pavel Pisa
Tested-by:
Hello Peter,
On Tuesday 10 of November 2020 22:18:45 Peter Maydell wrote:
> If you've got a modified patch set that you've tested, would
> you mind sending it out to the list? That would avoid my
> possibly making mistakes in updating patches on my end and
> then requiring you to repeat the
From: Peter Maydell
The ctucan driver defines types for its registers which are a union
of a uint32_t with a struct with bitfields for the individual
fields within that register. This is a bad idea, because bitfields
aren't portable. The ctu_can_fd_regs.h header works around the
most glaring of
From: Peter Maydell
Coverity points out that in ctucan_send_ready_buffers() we
set buff_st_mask = 0xf << (i * 4) inside the loop, but then
we never use it before overwriting it later.
The only thing we use the mask for is as part of the code that is
inserting the new buff_st field into
Credit for finding and fixes goes to Peter Maydell
This patchset fixes a couple of issues spotted by Coverity:
* incorrect address checks meant the guest could write off the
end of the tx_buffer arrays
* we had an unused value in ctucan_send_ready_buffers()
and also some I noticed while
From: Peter Maydell
The ctucan device has 4 CAN bus cores, each of which has a set of 20
32-bit registers for writing the transmitted data. The registers are
however not contiguous; each core's buffers is 0x100 bytes after
the last.
We got the checks on the address wrong in the
On Tue, Nov 10, 2020 at 08:20:50AM -0700, Alex Williamson wrote:
> External email: Use caution opening links or attachments
>
>
> On Tue, 10 Nov 2020 19:46:20 +0530
> Kirti Wankhede wrote:
>
> > On 11/10/2020 2:40 PM, Dr. David Alan Gilbert wrote:
> > > * Alex Williamson
On Tue, 10 Nov 2020 at 19:32, Pavel Pisa wrote:
>
> Hello Peter,
>
> On Tuesday 10 of November 2020 19:24:03 Peter Maydell wrote:
> > For unaligned accesses, for 6.0, I think the code for doing
> > them to the txbuff at least is straightforward:
> >
> >if (buff_num < CTUCAN_CORE_TXBUF_NUM &&
motes/alistair/tags/pull-riscv-to-apply-20201109' into staging (2020-11-10
> 09:24:56 +)
>
> are available in the Git repository at:
>
> https://git.linaro.org/people/pmaydell/qemu-arm.git
> tags/pull-target-arm-20201110
>
> for you to fetch changes up to b6c5
On Tue, 10 Nov 2020 at 19:37, Pavel Pisa wrote:
>
> Hello Peter,
>
> On Tuesday 10 of November 2020 18:06:02 Peter Maydell wrote:
> > @@ -256,10 +254,7 @@ static void ctucan_send_ready_buffers(CtuCanCoreState
> > *s) for (i = 0; i < CTUCAN_CORE_TXBUF_NUM; i++) {
> > uint32_t prio;
>
On 11/8/20 8:19 PM, Philippe Mathieu-Daudé wrote:
Extract the common definitions shared by '.native_build_job'
and '.native_test_job' to '.native_common_job'.
Signed-off-by: Philippe Mathieu-Daudé
---
.gitlab-ci.yml | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
On Tue, Nov 10, 2020 at 09:39:37PM +0100, Paolo Bonzini wrote:
> On 10/11/20 18:55, Eduardo Habkost wrote:
> > > I think we should not try yo implement interfaces conditionally (i.e. have
> > > TYPE_X86_ACCEL implemented only on qemu-system-{i386,x86_64} and not
> > > qemu-system-arm), even if
On 11/8/20 8:19 PM, Philippe Mathieu-Daudé wrote:
Extract the common definitions shared by '.cross_system_build_job'
and '.cross_user_build_job' to '.cross_common_job'.
Signed-off-by: Philippe Mathieu-Daudé
---
.gitlab-ci.d/crossbuilds.yml | 9 +
1 file changed, 5 insertions(+), 4
Once Cleber said "acceptance" wasn't a good name for those tests.
Indeed "integration" is widely used, so okay for this renaming.
On 11/8/20 8:19 PM, Philippe Mathieu-Daudé wrote:
Signed-off-by: Philippe Mathieu-Daudé
---
.gitlab-ci.yml | 18 +-
1 file changed, 9
On 10/11/20 18:55, Eduardo Habkost wrote:
I think we should not try yo implement interfaces conditionally (i.e. have
TYPE_X86_ACCEL implemented only on qemu-system-{i386,x86_64} and not
qemu-system-arm), even if technically the accel/ objects are per-target
(specific_ss) rather than common.
If
On 11/8/20 8:19 PM, Philippe Mathieu-Daudé wrote:
'extends' is an alternative to using YAML anchors
and is a little more flexible and readable. See:
https://docs.gitlab.com/ee/ci/yaml/#extends
Signed-off-by: Philippe Mathieu-Daudé
---
.gitlab-ci.yml | 15 ++-
1 file changed, 6
On 11/8/20 8:19 PM, Philippe Mathieu-Daudé wrote:
'extends' is an alternative to using YAML anchors
and is a little more flexible and readable. See:
https://docs.gitlab.com/ee/ci/yaml/#extends
Signed-off-by: Philippe Mathieu-Daudé
---
.gitlab-ci.yml | 26 +-
1 file
On 11/8/20 8:19 PM, Philippe Mathieu-Daudé wrote:
'extends' is an alternative to using YAML anchors
and is a little more flexible and readable. See:
https://docs.gitlab.com/ee/ci/yaml/#extends
Signed-off-by: Philippe Mathieu-Daudé
---
.gitlab-ci.yml | 32
On 11/8/20 8:19 PM, Philippe Mathieu-Daudé wrote:
'extends' is an alternative to using YAML anchors
and is a little more flexible and readable. See:
https://docs.gitlab.com/ee/ci/yaml/#extends
Good idea!
Signed-off-by: Philippe Mathieu-Daudé
---
.gitlab-ci.d/crossbuilds.yml | 40
On Tue, 10 Nov 2020 09:53:49 +
Stefan Hajnoczi wrote:
> VFIO mdev Drivers
> -
> The following mdev type sysfs attrs are available for managing device
> instances::
>
> /sys/...//mdev_supported_types//
> create - writing a UUID to this file instantiates a device
>
Hi Richard, what's the plan to get this patch series into master?
Thanks,
Stephen
Hello Peter,
On Tuesday 10 of November 2020 18:06:02 Peter Maydell wrote:
> Coverity points out that in ctucan_send_ready_buffers() we
> set buff_st_mask = 0xf << (i * 4) inside the loop, but then
> we never use it before overwriting it later.
>
> The only thing we use the mask for is as part of
Hello Peter,
On Tuesday 10 of November 2020 18:06:03 Peter Maydell wrote:
> The ctucan driver defines types for its registers which are a union
> of a uint32_t with a struct with bitfields for the individual
> fields within that register. This is a bad idea, because bitfields
> aren't portable.
Hello Peter,
On Tuesday 10 of November 2020 19:24:03 Peter Maydell wrote:
> For unaligned accesses, for 6.0, I think the code for doing
> them to the txbuff at least is straightforward:
>
>if (buff_num < CTUCAN_CORE_TXBUF_NUM &&
>(addr + size) < CTUCAN_CORE_MSG_MAX_LEN) {
>
This allows us to do:
./scripts/ci/gitlab-pipeline-status -w -b HEAD -p 2961854
to check out own pipeline status of a recently pushed branch.
Signed-off-by: Alex Bennée
---
scripts/ci/gitlab-pipeline-status | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
Philippe Mathieu-Daudé writes:
> Similarly to commit 8cdb2cef3f1, move the linux-user (debug-tcg)
> test to GitLab.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Cc: Laurent Vivier
> ---
> .gitlab-ci.yml | 7 +++
> .travis.yml| 9 -
> 2 files changed, 7 insertions(+), 9
From: Philippe Mathieu-Daudé
This test is regularly failing on CI:
(05/34)
tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_microblaze_s3adsp1800:
Linux version 4.11.3 (th...@thuth.remote.csb) (gcc version 6.4.0 (Buildroot
2018.05.2) ) #5 Tue Dec 11 11:56:23 CET 2018
...
The GCC check-tcg (user) test in particular was very prone to timing
out on Travis. We only actually need to move the some-softmmu builds
across as we already have coverage for linux-user.
As --enable-debug-tcg does increase the run time somewhat as more
debug is put in let's restrict that to
Xen is supported on ARM although weirdly using the i386-softmmu model.
Checking based on the host CPU meant we never enabled Xen support. It
would be nice to enable CONFIG_XEN for aarch64-softmmu to make it not
seem weird but that will require further build surgery.
Fixes: 8a19980e3f ("configure:
We should never build something that calls this without having it.
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20201105175153.30489-13-alex.ben...@linaro.org>
Signed-off-by: Alex Bennée
---
stubs/xen-hw-stub.c | 4
1 file changed, 4 deletions(-)
diff
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20201105175153.30489-14-alex.ben...@linaro.org>
Signed-off-by: Alex Bennée
---
accel/stubs/hax-stub.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/accel/stubs/hax-stub.c b/accel/stubs/hax-stub.c
index
Chardev is already a typedef'ed struct.
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20201105175153.30489-12-alex.ben...@linaro.org>
Signed-off-by: Alex Bennée
---
include/hw/xen/xen.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Philippe Mathieu-Daudé
GCC 9.3.0 thinks that 'method' can be left uninitialized. This code
is already in the "if (bsel || pcihp_bridge_en)" block statement,
but it isn't smart enough to figure it out.
Restrict the code to be used only in the "if (bsel || pcihp_bridge_en)"
block statement
From: Alex Chen
Close the fd when the connect() fails.
Reported-by: Euler Robot
Signed-off-by: Alex Chen
Message-Id: <20201109082829.87496-2-alex.c...@huawei.com>
Signed-off-by: Alex Bennée
---
contrib/plugins/lockstep.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi,
This collects together a bunch of fixes for 5.2:
- a few resource leak fixes for plugins
- Xen on arm64 build fixes (from my larger Xen series)
- a couple of build and CI fixes
- a tweak to the gitlab status script
I can drop the last patch if I have to but it hopefully allows for
From: Alex Chen
Either accept() fails or exits normally, we need to close the fd.
Reported-by: Euler Robot
Signed-off-by: Alex Chen
Message-Id: <20201109082829.87496-3-alex.c...@huawei.com>
Signed-off-by: Alex Bennée
---
contrib/plugins/lockstep.c | 2 ++
1 file changed, 2 insertions(+)
On 11/9/20 5:49 PM, Like Xu wrote:
Hi Krish,
On 2020/11/10 9:23, Krish Sadhukhan wrote:
@@ -1192,7 +1192,7 @@ void vmx_set_host_fs_gs(struct vmcs_host_state
*host, u16 fs_sel, u16 gs_sel,
}
}
-void vmx_prepare_switch_to_guest(struct kvm_vcpu *vcpu)
+void
* Max Reitz (mre...@redhat.com) wrote:
> Contrary to what the check (and warning) in lo_init() claims, we can
> announce submounts just fine even without statx() -- the check is based
> on comparing both the mount ID and st_dev of parent and child. Without
> statx(), we will not have the mount
On Tue, Nov 10, 2020 at 12:46:48PM -0500, Eduardo Habkost wrote:
> On Tue, Nov 10, 2020 at 04:08:16PM +0100, Paolo Bonzini wrote:
> > On 10/11/20 16:03, Eduardo Habkost wrote:
> > > > Does anyone have any arguments for which solution is preferred?
> > > I'd say (2) is preferred, as we don't expect
On Tue, 10 Nov 2020 at 18:02, Pavel Pisa wrote:
>
> Hello Peter,
>
> On Tuesday 10 of November 2020 18:06:01 Peter Maydell wrote:
> > The ctucan device has 4 CAN bus cores, each of which has a set of 20
> > 32-bit registers for writing the transmitted data. The registers are
> > however not
On Tue, Nov 10, 2020 at 06:38:49PM +0100, Claudio Fontana wrote:
> On 11/10/20 4:23 PM, Eduardo Habkost wrote:
> > On Tue, Nov 10, 2020 at 11:41:46AM +0100, Paolo Bonzini wrote:
> >> On 10/11/20 11:04, Daniel P. Berrangé wrote:
> >>>
> >>> ie, we should have one class hierarchy for CPU model
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
On Tue, Nov 10, 2020 at 05:39:08PM +0100, Paolo Bonzini wrote:
> On 09/11/20 22:25, Eduardo Habkost wrote:
> > Based-on: 20201104160021.2342108-1-ehabk...@redhat.com
> > Git branch:
> > https://gitlab.com/ehabkost/qemu/-/commits/work/qdev-qlit-defaults
> >
> > This extend qlit.h to support all
On 11/8/20 6:45 PM, Philippe Mathieu-Daudé wrote:
Similarly to commit 8cdb2cef3f1, move the trace backend
tests to GitLab.
Signed-off-by: Philippe Mathieu-Daudé
---
Cc: Stefan Hajnoczi
---
.gitlab-ci.yml | 18 ++
.travis.yml| 19 ---
2 files changed,
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
** Changed in: qemu
Status: New => Won't Fix
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1737882
Title:
QEMU Zaurus cannot boot 2.4.x kernels
Status in QEMU:
Won't Fix
Bug
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
Hello Peter,
On Tuesday 10 of November 2020 18:06:04 Peter Maydell wrote:
> Instead of casting an address within a uint8_t array to a
> uint32_t*, use stl_le_p(). This handles possibly misaligned
> addresses which would otherwise crash on some hosts.
>
> Signed-off-by: Peter Maydell
>
Hello Peter,
On Tuesday 10 of November 2020 18:06:01 Peter Maydell wrote:
> The ctucan device has 4 CAN bus cores, each of which has a set of 20
> 32-bit registers for writing the transmitted data. The registers are
> however not contiguous; each core's buffers is 0x100 bytes after
> the last.
>
Have you ever tried the suggestions from Liang Yan ?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1736042
Title:
qemu-system-x86_64 does not
Which version of QEMU did you test? Does it work better with the latest
version of QEMU now?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Can you reproduce the problem with the latest official upstream version
of QEMU?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1735082
Title:
FWIW, it's a syscall that's been around for as long as I can remember.
In macOS 11 they added a new mach_vm_remap but kept the old one for
compatibility so I don't think it's going away any time soon.
-j
On Tue, Nov 10, 2020 at 9:37 AM Alex Bennée wrote:
>
>
> Richard Henderson writes:
>
> >
On Tue, Nov 10, 2020 at 05:05:27PM +0100, Paolo Bonzini wrote:
> On 10/11/20 16:23, Eduardo Habkost wrote:
> > On Tue, Nov 10, 2020 at 11:41:46AM +0100, Paolo Bonzini wrote:
> > > On 10/11/20 11:04, Daniel P. Berrangé wrote:
> > > >
> > > > ie, we should have one class hierarchy for CPU model
On Tue, Nov 10, 2020 at 04:08:16PM +0100, Paolo Bonzini wrote:
> On 10/11/20 16:03, Eduardo Habkost wrote:
> > > Does anyone have any arguments for which solution is preferred?
> > I'd say (2) is preferred, as we don't expect object_new(T) to
> > have any side effects outside the object instance
1 - 100 of 326 matches
Mail list logo
