On 6/4/20 8:42 AM, David Gibson wrote:
> The SEV code uses a pretty ugly global to access its internal state. Now
> that SEVState is embedded in SevGuestState, we can avoid accessing it via
> the global in some cases. In the remaining cases use a new global
> referencing the containing SevGuestSt
On 5/28/20 9:37 PM, Roman Bolshakov wrote:
> Drop and replace rip field from HVFX86EmulatorState in favor of eip from
> common CPUX86State.
>
> Signed-off-by: Roman Bolshakov
> ---
> target/i386/hvf/hvf.c| 6 +--
> target/i386/hvf/x86.h| 3 --
> target/i386/hvf/x86_decode.c |
SEVState is contained with SevGuestState. We've now fixed redundancies
and name conflicts, so there's no real point to the nested structure. Just
move all the fields of SEVState into SevGuestState.
This eliminates the SEVState structure, which as a bonus removes the
confusion with the SevState e
On 5/28/20 9:37 PM, Roman Bolshakov wrote:
> The lazy flags are still needed for instruction decoder.
>
> Signed-off-by: Roman Bolshakov
> ---
> include/sysemu/hvf.h| 7 +
> target/i386/cpu.h | 2 ++
> target/i386/hvf/x86.h | 6
> target/i386/hvf/x86_flags.c |
SEVState::policy is set from the final value of the policy field in the
parameter structure for the KVM_SEV_LAUNCH_START ioctl(). But, AFAICT
that ioctl() won't ever change it from the original supplied value which
comes from SevGuestState::policy.
So, remove this field and just use SevGuestState
The user can explicitly specify a handle via the "handle" property wired
to SevGuestState::handle. That gets passed to the KVM_SEV_LAUNCH_START
ioctl() which may update it, the final value being copied back to both
SevGuestState::handle and SEVState::handle.
AFAICT, nothing will be looking SEVSta
The SEV code uses a pretty ugly global to access its internal state. Now
that SEVState is embedded in SevGuestState, we can avoid accessing it via
the global in some cases. In the remaining cases use a new global
referencing the containing SevGuestState which will simplify some future
transformat
The SEVState structure has cbitpos and reduced_phys_bits fields which are
simply copied from the SevGuestState structure and never changed. Now that
SEVState is embedded in SevGuestState we can just access the original copy
directly.
Signed-off-by: David Gibson
Reviewed-by: Philippe Mathieu-Daud
At the moment this is a purely passive object which is just a container for
information used elsewhere, hence the name. I'm going to change that
though, so as a preliminary rename it to SevGuestState.
That name risks confusion with both SEVState and SevState, but I'll be
working on that in follow
On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote:
>
> Hello David,
>
> David Gibson writes:
>
> > A number of hardware platforms are implementing mechanisms whereby the
> > hypervisor does not have unfettered access to guest memory, in order
> > to mitigate the security imp
Neither QSevGuestInfo nor SEVState (not to be confused with SevState) is
used anywhere outside target/i386/sev.c, so they might as well live in
there rather than in a (somewhat) exposed header.
Signed-off-by: David Gibson
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
t
This series has an assortment of cleanups to the AMD SEV memory
encryption code. Amongst other things it:
* Removes the confusion between struct SEVState and enum SevState
* Reduces use of global variables
* Unifies some ad-hoc structures with an existing QOM object
I made these changes alo
On Thu, Jun 04, 2020 at 08:19:41AM +0200, Thomas Huth wrote:
> On 04/06/2020 07.56, David Gibson wrote:
> > On Mon, Jun 01, 2020 at 08:54:42PM -0700, Richard Henderson wrote:
> >> On 5/20/20 8:43 PM, David Gibson wrote:
> >>> +++ b/include/hw/boards.h
> >>> @@ -12,6 +12,8 @@
> >>> #include "qom/ob
This structure is nothing but an empty wrapper around the parent class,
which by QOM conventions means we don't need it at all.
Signed-off-by: David Gibson
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
target/i386/sev.c | 1 -
target/i386/sev_i386.h | 5 -
2 f
Currently SevGuestState contains only configuration information. For
runtime state another non-QOM struct SEVState is allocated separately.
Simplify things by instead embedding the SEVState structure in
SevGuestState.
Signed-off-by: David Gibson
Reviewed-by: Richard Henderson
Reviewed-by: Phil
On 06/04/2020 11:22 AM, Richard Henderson wrote:
On 6/3/20 7:58 PM, Wei Wang wrote:
It is possible that encoded_size==0, but unencoded_size !=0. For example,
a page is written with the same data that it already has.
That really contains 0 bytes?
Not even the ones that say "same data"?
Yes. It
On 5/28/20 9:37 PM, Roman Bolshakov wrote:
> There's no need to read VMCS twice, instruction length is already
> available in ins_len.
>
> Signed-off-by: Roman Bolshakov
> ---
> target/i386/hvf/hvf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/i386/hvf/hvf.c
On 5/28/20 9:37 PM, Roman Bolshakov wrote:
> They're either declared elsewhere or have no use.
>
> While at it, rename _hvf_cpu_synchronize_post_init() to
> do_hvf_cpu_synchronize_post_init().
>
> Signed-off-by: Roman Bolshakov
> ---
> include/sysemu/hvf.h | 22 --
> target
> -Original Message-
> From: Zhanghailiang
> Sent: Wednesday, June 3, 2020 5:39 PM
> To: Zhang, Chen ; Dr . David Alan Gilbert
> ; Juan Quintela ; qemu-dev
>
> Cc: Zhang Chen ; Jason Wang
>
> Subject: RE: [PATCH 3/3] migration/colo: Merge multi checkpoint request
> into one.
>
> > --
On 5/28/20 9:37 PM, Roman Bolshakov wrote:
> Signed-off-by: Roman Bolshakov
> ---
> target/i386/hvf/x86.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/target/i386/hvf/x86.h b/target/i386/hvf/x86.h
> index c95d5b2116..56fcde13c6 100644
> --- a/target/i386/hvf/x86.h
> +++ b/target/i386/
On 6/3/20 4:52 PM, Guenter Roeck wrote:
> Set vendor property to IMX to enable IMX specific functionality
> in sdhci code.
>
> Tested-by: Philippe Mathieu-Daudé
> Signed-off-by: Guenter Roeck
> ---
> v2: Added missing error checks
> Added Philippe's Tested-by: tag
>
> hw/arm/fsl-imx25.c |
On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote:
>
> Hello David,
>
> David Gibson writes:
>
> > A number of hardware platforms are implementing mechanisms whereby the
> > hypervisor does not have unfettered access to guest memory, in order
> > to mitigate the security imp
Patch posted:
https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00856.html
** 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/1878628
Title:
On 04/06/2020 07.56, David Gibson wrote:
> On Mon, Jun 01, 2020 at 08:54:42PM -0700, Richard Henderson wrote:
>> On 5/20/20 8:43 PM, David Gibson wrote:
>>> +++ b/include/hw/boards.h
>>> @@ -12,6 +12,8 @@
>>> #include "qom/object.h"
>>> #include "hw/core/cpu.h"
>>>
>>> +typedef struct GuestMemo
On Mon, May 25, 2020 at 12:26:55PM +0200, Greg Kurz wrote:
>
> s/encrption/encryption
Fixed.
> On Thu, 21 May 2020 13:42:57 +1000
> David Gibson wrote:
>
> > At the moment AMD SEV sets a special function pointer, plus an opaque
> > handle in KVMState to let things know how to encrypt guest mem
On Mon, Jun 01, 2020 at 10:16:18AM +0100, Dr. David Alan Gilbert wrote:
> * Sean Christopherson (sean.j.christopher...@intel.com) wrote:
> > On Thu, May 21, 2020 at 01:42:46PM +1000, David Gibson wrote:
> > > A number of hardware platforms are implementing mechanisms whereby the
> > > hypervisor do
On Fri, May 29, 2020 at 12:59:40AM -0700, Ram Pai wrote:
> On Thu, May 21, 2020 at 01:43:03PM +1000, David Gibson wrote:
> > Some upcoming POWER machines have a system called PEF (Protected
> > Execution Framework) which uses a small ultravisor to allow guests to
>
> Framework -> Facility
>
> > r
On Fri, May 29, 2020 at 11:09:41AM +0200, Philippe Mathieu-Daudé wrote:
> On 5/21/20 5:42 AM, David Gibson wrote:
> > Currently SevGuestState contains only configuration information. For
> > runtime state another non-QOM struct SEVState is allocated separately.
> >
> > Simplify things by instead
On Fri, May 29, 2020 at 03:19:26PM -0700, Sean Christopherson wrote:
> On Thu, May 21, 2020 at 01:42:46PM +1000, David Gibson wrote:
> > A number of hardware platforms are implementing mechanisms whereby the
> > hypervisor does not have unfettered access to guest memory, in order
> > to mitigate th
On Mon, Jun 01, 2020 at 08:54:42PM -0700, Richard Henderson wrote:
> On 5/20/20 8:43 PM, David Gibson wrote:
> > +++ b/include/hw/boards.h
> > @@ -12,6 +12,8 @@
> > #include "qom/object.h"
> > #include "hw/core/cpu.h"
> >
> > +typedef struct GuestMemoryProtection GuestMemoryProtection;
> > +
>
On 6/4/20 5:45 AM, Richard Henderson wrote:
> Clang 10 enables this by default with -Wtype-limit.
>
> All of the instances flagged by this Werror so far have been
> cases in which we really do want the compiler to optimize away
> the test completely. Disabling the warning will avoid having
> to a
Patch posted:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg706322.html
** 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/1878627
Title:
a
On 6/4/20 12:13 AM, BALATON Zoltan wrote:
> On Thu, 4 Jun 2020, P J P wrote:
>> From: Prasad J Pandit
>>
>> While reading PCI configuration bytes, a guest may send an
>> address towards the end of the configuration space. It may lead
>> to an OOB access issue. Assert that 'address + len' is within
On Wed, Jun 3, 2020 at 10:06 PM LIU Zhiwei wrote:
>
>
>
> On 2020/6/4 12:35, Alistair Francis wrote:
> > On Wed, Jun 3, 2020 at 6:59 PM LIU Zhiwei wrote:
> >>
> >>
> >> On 2020/6/3 23:56, Alistair Francis wrote:
> >>> On Wed, Jun 3, 2020 at 3:33 AM LIU Zhiwei wrote:
> On 2020/6/3 1:54, Alis
On 2020/6/4 12:35, Alistair Francis wrote:
On Wed, Jun 3, 2020 at 6:59 PM LIU Zhiwei wrote:
On 2020/6/3 23:56, Alistair Francis wrote:
On Wed, Jun 3, 2020 at 3:33 AM LIU Zhiwei wrote:
On 2020/6/3 1:54, Alistair Francis wrote:
On Tue, Jun 2, 2020 at 5:28 AM LIU Zhiwei wrote:
Hi Alista
+-- On Thu, 4 Jun 2020, BALATON Zoltan wrote --+
| On Thu, 4 Jun 2020, P J P wrote:
| > +assert(address + len <= pci_config_size(d));
|
| Does this allow guest now to crash QEMU?
Yes, possible. Such crash (assert failure) can be a regular bug, as reading
PCI configuration is likely a privile
Hi,
> > +assert(address + len <= pci_config_size(d));
>
> Does this allow guest now to crash QEMU?
Looks like it does (didn't actually try though).
> I think it was suggested that assert should only be used for cases
> that can only arise from a programming error and not from values set
>
On 04/06/2020 05.45, Richard Henderson wrote:
> Clang 10 enables this by default with -Wtype-limit.
>
> All of the instances flagged by this Werror so far have been
> cases in which we really do want the compiler to optimize away
> the test completely. Disabling the warning will avoid having
> to
On 2020/6/4 12:35, Alistair Francis wrote:
On Wed, Jun 3, 2020 at 6:59 PM LIU Zhiwei wrote:
On 2020/6/3 23:56, Alistair Francis wrote:
On Wed, Jun 3, 2020 at 3:33 AM LIU Zhiwei wrote:
On 2020/6/3 1:54, Alistair Francis wrote:
On Tue, Jun 2, 2020 at 5:28 AM LIU Zhiwei wrote:
Hi Alista
On Wed, Jun 3, 2020 at 6:59 PM LIU Zhiwei wrote:
>
>
>
> On 2020/6/3 23:56, Alistair Francis wrote:
> > On Wed, Jun 3, 2020 at 3:33 AM LIU Zhiwei wrote:
> >> On 2020/6/3 1:54, Alistair Francis wrote:
> >>> On Tue, Jun 2, 2020 at 5:28 AM LIU Zhiwei wrote:
> Hi Alistair,
>
> There a
ping
On Thu, May 21, 2020 at 1:00 AM Raphael Norwitz
wrote:
>
> In QEMU today, a VM with a vhost-user device can hot add memory a
> maximum of 8 times. See these threads, among others:
>
> [1] https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg01046.html
> https://lists.gnu.org/archive/
Clang 10 enables this by default with -Wtype-limit.
All of the instances flagged by this Werror so far have been
cases in which we really do want the compiler to optimize away
the test completely. Disabling the warning will avoid having
to add ifdefs to work around this.
Signed-off-by: Richard H
On 6/3/20 6:50 PM, agrecascino...@gmail.com wrote:
> static inline void tcg_out_shri64(TCGContext *s, TCGReg dst, TCGReg src, int
> c)
> {
> +tcg_debug_assert((c < 64) && (c >= 0));
> tcg_out_rld(s, RLDICL, dst, src, 64 - c, c);
> }
>
> @@ -2610,21 +2614,33 @@ static void tcg_out_op(
On 6/3/20 7:58 PM, Wei Wang wrote:
> It is possible that encoded_size==0, but unencoded_size !=0. For example,
> a page is written with the same data that it already has.
That really contains 0 bytes?
Not even the ones that say "same data"?
You certainly have a magical compression algorithm there
On 06/04/2020 03:28 AM, Richard Henderson wrote:
On Wed, 29 Apr 2020 at 18:54, Wei Wang wrote:
+if (xbzrle_counters.pages == rs->xbzrle_pages_prev) {
+xbzrle_counters.encoding_rate = 0;
+} else if (!encoded_size) {
+xbzrle_counters.encoding_rate = UINT64_
On 2020/6/3 23:56, Alistair Francis wrote:
On Wed, Jun 3, 2020 at 3:33 AM LIU Zhiwei wrote:
On 2020/6/3 1:54, Alistair Francis wrote:
On Tue, Jun 2, 2020 at 5:28 AM LIU Zhiwei wrote:
Hi Alistair,
There are still some questions I don't understand.
1. Is the baud rate or fifo a necessary
Reviewed-by: Cameron Esfahani
Cameron Esfahani
di...@apple.com
"The cake is a lie."
Common wisdom
> On May 28, 2020, at 12:37 PM, Roman Bolshakov wrote:
>
> Hi,
>
> This is a cleanup series for HVF accel.
>
> HVF is using two emulator states CPUX86State and HVFX86EmulatorState
> simulta
From: "Catherine A. Frederick"
Signed-off-by: Catherine A. Frederick
---
This should finally do it, sorry for the style issues on v3.
tcg/ppc/tcg-target.inc.c | 41 ++--
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/tcg/ppc/tcg-target.inc.c
From: Chen Gang
Another DRM_IOCTL_* commands will be done later.
Signed-off-by: Chen Gang
---
configure | 10
linux-user/ioctls.h| 5 ++
linux-user/syscall.c | 95 ++
linux-user/syscall_defs.h | 15 ++
linux-user/sys
Reviewed-by: Cameron Esfahani
Cameron Esfahani
di...@apple.com
"It is the spirit and not the form of law that keeps justice alive."
Earl Warren
> On Jun 1, 2020, at 5:42 AM, Roman Bolshakov wrote:
>
> ld64 is making PIE executables for 10.7 and above by default, as
> documented in ld(1).
OK, thanks. I'll send patch v6. :)
On 2020/6/3 下午8:03, Laurent Vivier wrote:
> Le 03/06/2020 à 13:05, Chen Gang a écrit :
>> On 2020/6/3 下午5:49, Laurent Vivier wrote:
>>> Le 03/06/2020 à 03:08, cheng...@emindsoft.com.cn a écrit :
+#ifdef HAVE_DRM_H
+
+static void unlock_drm_version(
Hi, Alexandar,
On Wed, Jun 3, 2020 at 10:34 PM Aleksandar Markovic
wrote:
>
>
>
> уто, 2. јун 2020. у 04:38 Huacai Chen је написао/ла:
>>
>> MIPS has two types of KVM: TE & VZ, and TE is the default type. Now we
>> can't create a VZ guest in QEMU because it lacks the kvm_type() hook in
>> Machin
Started looking at this. Let me know if you have any ideas. Will respond
with more details later this week.
> -Original Message-
> From: Eduardo Habkost
> Sent: Tuesday, June 2, 2020 12:52 PM
> To: Moger, Babu
> Cc: m...@redhat.com; marcel.apfelb...@gmail.com; pbonz...@redhat.com;
> r...
Reviewed-by: Cameron Esfahani
Cameron Esfahani
di...@apple.com
"Americans are very skilled at creating a custom meaning from something that's
mass-produced."
Ann Powers
> On May 7, 2020, at 6:16 AM, Gerd Hoffmann wrote:
>
> Use a single io range for _CRS instead of two,
> following what re
Commit message typo tcg_allowed -> hvf_allowed.
If fixed:
Reviewed-by: Cameron Esfahani
Cameron Esfahani
di...@apple.com
"You only live once, and the way I live, once is enough"
Frank Sinatra
> On May 9, 2020, at 6:09 AM, Philippe Mathieu-Daudé wrote:
>
> When HVF is not available, the tc
Oh dear, I did it to myself again.
On Wed, Jun 3, 2020 at 7:13 PM wrote:
>
> From: "Catherine A. Frederick"
>
> Signed-off-by: Catherine A. Frederick
> ---
> tcg/ppc/tcg-target.inc.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/tcg/ppc/
From: "Catherine A. Frederick"
Signed-off-by: Catherine A. Frederick
---
tcg/ppc/tcg-target.inc.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/tcg/ppc/tcg-target.inc.c b/tcg/ppc/tcg-target.inc.c
index 7da67086c6..3cab56fe91 100644
--- a/tcg/p
在 2020/6/4 上午12:14, Li Qiang 写道:
After build qemu with '-fsanitize=address' extra-cflags,
'make check' show following leak:
=
==44580==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 2500 byte(s) in 1 object(s) allocated
If we use QLNULL for null lockables, we can always
use referencing unknown_lock_type as a link time
error indicator.
Signed-off-by: Joe Slater
---
include/qemu/lockable.h | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/include/qemu/lockable.h b/include/qe
We currently will fail to build for optimizations like -Og because they do not
eliminate dead code. We do not need such clean up if we use QLNULL. There is
no
need to produce a QemuLockable that will be thrown away.
Only testing:
$ ../configure
$ make -j16 CFLAGS="$CFLAGS" # which I set t
Allows us to build with -Og and optimizations that
do not clean up dead-code.
Signed-off-by: Joe Slater
to be squished
Signed-off-by: Joe Slater
---
block/block-backend.c | 4 ++--
block/block-copy.c | 2 +-
block/mirror.c | 5 +++--
fsdev/qemu-fsdev-throt
On Thu, 4 Jun 2020, P J P wrote:
From: Prasad J Pandit
While reading PCI configuration bytes, a guest may send an
address towards the end of the configuration space. It may lead
to an OOB access issue. Assert that 'address + len' is within
PCI configuration space.
Suggested-by: Philippe Mathie
> -Original Message-
> From: Eduardo Habkost
> Sent: Wednesday, June 3, 2020 10:46 AM
> To: Moger, Babu
> Cc: marcel.apfelb...@gmail.com; pbonz...@redhat.com; r...@twiddle.net;
> m...@redhat.com; imamm...@redhat.com; qemu-devel@nongnu.org
> Subject: Re: [PATCH v7 07/13] hw/386: Add EPY
On Thu, 4 Jun 2020, P J P wrote:
From: Prasad J Pandit
While reading PCI configuration bytes, a guest may send an
address towards the end of the configuration space. It may lead
to an OOB access issue. Add check to ensure 'address + size' is
within PCI configuration space.
Reported-by: Ren Din
On Thu, 4 Jun 2020, P J P wrote:
From: Prasad J Pandit
While accessing VGA registers via ati_mm_read/write routines,
a guest may set 's->regs.mm_index' such that it leads to infinite
recursion. Check mm_index value to avoid it.
Reported-by: Ren Ding
Reported-by: Hanqing Zhao
Reported-by: Yi
From: Prasad J Pandit
While reading PCI configuration bytes, a guest may send an
address towards the end of the configuration space. It may lead
to an OOB access issue. Add check to ensure 'address + size' is
within PCI configuration space.
Reported-by: Ren Ding
Reported-by: Hanqing Zhao
Repor
From: Prasad J Pandit
While reading PCI configuration bytes, a guest may send an
address towards the end of the configuration space. It may lead
to an OOB access issue. Assert that 'address + len' is within
PCI configuration space.
Suggested-by: Philippe Mathieu-Daudé
Signed-off-by: Prasad J Pa
From: Prasad J Pandit
Hello,
This patch series fixes
1. While reading PCI configuration bytes, a guest may send an address towards
the end of the configuration space. It may lead to an OOB access issue.
Add check to ensure 'addr + size' is within bounds.
2. Assert that PCI configuration
On Wed, 29 Apr 2020 at 18:54, Wei Wang wrote:
> +if (xbzrle_counters.pages == rs->xbzrle_pages_prev) {
> +xbzrle_counters.encoding_rate = 0;
> +} else if (!encoded_size) {
> +xbzrle_counters.encoding_rate = UINT64_MAX;
> +} else {
> +xbzr
On 6/3/20 11:32 AM, Richard Henderson wrote:
I'd prefer we generate a compile-time error than a runtime trap (or nothing,
depending on compiler flags controlling __builtin_unreachable).
What we have DOES produce a compile-time error. If either expression to
MIN_CONST() is not actually const,
On 6/3/20 8:55 PM, P J P wrote:
> From: Prasad J Pandit
>
> While accessing VGA registers via ati_mm_read/write routines,
> a guest may set 's->regs.mm_index' such that it leads to infinite
> recursion. Check mm_index value to avoid it.
>
> Reported-by: Ren Ding
> Reported-by: Hanqing Zhao
> R
+-- On Wed, 3 Jun 2020, BALATON Zoltan wrote --+
| or even > MM_DATA + 3 may be best as that only refers to defines used in
| that case. So maybe
|
| + } else if (s->regs.mm_index > MM_DATA + 3) {
| > ati_mm_write(s, s->regs.mm_index + addr - MM_DATA, data, size);
| > }
| >
| > and do the s
From: Prasad J Pandit
While accessing VGA registers via ati_mm_read/write routines,
a guest may set 's->regs.mm_index' such that it leads to infinite
recursion. Check mm_index value to avoid it.
Reported-by: Ren Ding
Reported-by: Hanqing Zhao
Reported-by: Yi Ren
Signed-off-by: Prasad J Pandit
> Account the memory to the configured nid.
>
> Cc: Eduardo Habkost
> Cc: Marcel Apfelbaum
> Cc: "Michael S. Tsirkin"
> Signed-off-by: David Hildenbrand
> ---
> hw/core/numa.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/hw/core/numa.c b/hw/core/numa.c
> index 316bc50d75..069
Only SCSD cards support Class 6 (Block Oriented Write Protection)
commands.
"SD Specifications Part 1 Physical Layer Simplified Spec. v3.01"
4.3.14 Command Functional Difference in Card Capacity Types
* Write Protected Group
SDHC and SDXC do not support write-protected groups. Issuing
On 03/06/2020 20.01, Richard Henderson wrote:
> On 6/3/20 9:06 AM, Eric Blake wrote:
>> Instead of using #if, the following suffices to shut up clang:
>>
>> diff --git c/linux-user/mmap.c w/linux-user/mmap.c
>> index e37803379747..8d9ba201625d 100644
>> --- c/linux-user/mmap.c
>> +++ w/linux-user/m
On 6/3/20 9:06 AM, Eric Blake wrote:
> Instead of using #if, the following suffices to shut up clang:
>
> diff --git c/linux-user/mmap.c w/linux-user/mmap.c
> index e37803379747..8d9ba201625d 100644
> --- c/linux-user/mmap.c
> +++ w/linux-user/mmap.c
> @@ -715,7 +715,7 @@ abi_long target_mremap(ab
Patchew URL:
https://patchew.org/QEMU/20200603160442.3151170-1-anthony.per...@citrix.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT B
Robert Foley writes:
> On Wed, 3 Jun 2020 at 07:43, Alex Bennée wrote:
>>
>>
>> Robert Foley writes:
>>
>
>> >
>> > When testing out the options, I noticed that
>> > if we supply arguments of "read", and "write", then we will only get
>> > the last one set, "write", since rw gets overwritten
On 6/3/20 6:14 PM, Li Qiang wrote:
> After build qemu with '-fsanitize=address' extra-cflags,
> 'make check' show following leak:
>
> =
> ==44580==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 2500 byte(s) in 1 objec
Peter Maydell writes:
> On Tue, 2 Jun 2020 at 16:54, Alex Bennée wrote:
>>
>> This is a plugin intended to help with profiling access to various
>> bits of system hardware. It only really makes sense for system
>> emulation.
>>
>> It takes advantage of the recently exposed helper API that allo
The 06/03/2020 09:21, Richard Henderson wrote:
> On 6/3/20 6:50 AM, Szabolcs Nagy wrote:
> > thanks my tests now get further but later i run into
> > the previous assert failure:
> >
> > target/arm/mte_helper.c:97:allocation_tag_mem: assertion failed: (tag_size
> > <= in_page)
> >
> > i might be
On Sonntag, 19. April 2020 17:06:17 CEST Christian Schoenebeck wrote:
> Make top half really top half and bottom half really bottom half:
>
> Each T_readdir request handling is hopping between threads (main
> I/O thread and background I/O driver threads) several times for
> every individual direct
On 03/06/20 18:04, Anthony PERARD wrote:
> From: Roger Pau Monne
>
> Xen PCI passthrough support may not be available and thus the global
> variable "has_igd_gfx_passthru" might be compiled out. Common code
> should not access it in that case.
>
> Unfortunately, we can't use CONFIG_XEN_PCI_PASST
On Wed, Jun 03, 2020 at 05:04:42PM +0100, Anthony PERARD wrote:
> From: Roger Pau Monne
>
> Xen PCI passthrough support may not be available and thus the global
> variable "has_igd_gfx_passthru" might be compiled out. Common code
> should not access it in that case.
>
> Unfortunately, we can't u
On Tue, 2 Jun 2020 at 15:22, Alex Bennée wrote:
>
>
> Robert Foley writes:
>
> > From: Lingfeng Yang
> >
> > +# Thread sanitizer is, for now, much noisier than the other sanitizers;
> > +# keep it separate until that is not the case.
>
> I think we also need to stop both being enabled at once.
On 5/24/20 9:48 AM, Philippe Mathieu-Daudé wrote:
> Convert APM_DPRINTF() to trace events and remove ifdef'ry.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/isa/apm.c| 15 +--
> hw/isa/trace-events | 4
> 2 files changed, 9 insertions(+), 10 deletions(-)
Reviewe
On 6/2/20 7:29 PM, Eric Blake wrote:
> Because:
>
> #if MIN(...)
>
> now fails to compile (you can't have { in a preprocessor expression), and:
>
> #if MIN_CONST(...)
>
> fails to compile (__builtin_constant_p() is not a preprocessor macro, so it
> warns that it is being treated as 0). The onl
After build qemu with '-fsanitize=address' extra-cflags,
'make check' show following leak:
=
==44580==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 2500 byte(s) in 1 object(s) allocated from:
#0 0x7f1b5a8b8d28 in __i
Signed-off-by: Alistair Francis
Reviewed-by: Bin Meng
---
docs/system/deprecated.rst | 33 ++---
target/riscv/cpu.h | 7 ---
target/riscv/cpu.c | 28
tests/qtest/machine-none-test.c | 4 ++--
4 files ch
Update the -bios deprecation documentation to describe the new
behaviour.
Signed-off-by: Alistair Francis
Reviewed-by: Bin Meng
---
docs/system/deprecated.rst | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/docs/system/deprecated.rst b/docs/sys
From: Bin Meng
Remove the riscv_ prefix of the machine* functions.
Signed-off-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Message-id: 1590072147-13035-2-git-send-email-bmeng...@gmail.com
Message-Id: <1590072147-13035-2-git-send-email-bmeng...@gmail.com>
Sign
From: Bin Meng
We only ship plain binary bios images in the QEMU source. With Spike
machine that uses ELF images as the default bios, running QEMU test
will complain hence let's suppress the error report for QEMU testing.
Signed-off-by: Bin Meng
Reviewed-by: Anup Patel
Message-Id: <1588348254-
On Wed, 3 Jun 2020 01:24:43 -0400
Yan Zhao wrote:
> On Tue, Jun 02, 2020 at 09:55:28PM -0600, Alex Williamson wrote:
> > On Tue, 2 Jun 2020 23:19:48 -0400
> > Yan Zhao wrote:
> >
> > > On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote:
> > > > On Wed, 29 Apr 2020 20:39:50 -040
From: Bin Meng
To keep consistency with the machine* functions, remove the riscv_
prefix of the soc* functions.
Signed-off-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Message-id: 1590072147-13035-1-git-send-email-bmeng...@gmail.com
Message-Id: <1590072147-13
Signed-off-by: Alistair Francis
Reviewed-by: Palmer Dabbelt
---
include/hw/riscv/sifive_e.h | 4
hw/riscv/sifive_e.c | 41 +++--
2 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/include/hw/riscv/sifive_e.h b/include/hw/riscv/sifive_e.
On 6/3/20 6:50 AM, Szabolcs Nagy wrote:
> thanks my tests now get further but later i run into
> the previous assert failure:
>
> target/arm/mte_helper.c:97:allocation_tag_mem: assertion failed: (tag_size <=
> in_page)
>
> i might be able to reduce it to a small reproducer
> this time. i assume
From: Bin Meng
Per QEMU deprecated doc, QEMU 4.1 introduced support for the -bios
option in QEMU for RISC-V for the virt machine and sifive_u machine.
The default behavior has been that QEMU does not automatically load
any firmware if no -bios option is included.
Now 2 releases passed, it's time
Le 02/06/2020 à 13:53, Filip Bozuta a écrit :
> From: Filip Bozuta
>
> This patch implements strace argument printing functionality for following
> syscalls:
>
> *getxattr, lgetxattr, fgetxattr - retrieve an extended attribute value
>
> ssize_t getxattr(const char *path, const char
The ISA specific Spike machines have been deprecated in QEMU since 4.1,
let's finally remove them.
Signed-off-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Bin Meng
Reviewed-by: Thomas Huth
---
docs/system/deprecated.rst | 17 +--
include/hw/riscv/spike.h | 6 +-
1 - 100 of 266 matches
Mail list logo
