On 12/01/2015 10:34 AM, Eduardo Habkost wrote:
BTW, if we are going to implement xsave in TCG, the
X86CPU<->xsave translation logic in kvm_{get,put}_xsave() could
be moved to generic code and reused by TCG instead of being
reimplemented.
That's not trivial.
In particular, stq_p isn't what the
On 12/01/2015 09:15 AM, Eduardo Habkost wrote:
On Tue, Dec 01, 2015 at 09:09:47AM -0800, Richard Henderson wrote:
On 11/30/2015 03:18 AM, Paolo Bonzini wrote:
Because this is always little endian, I would write it as uint8_t[16][16].
Maybe. That isn't altogether handy for TCG, since
On 11/30/2015 03:18 AM, Paolo Bonzini wrote:
Because this is always little endian, I would write it as uint8_t[16][16].
Maybe. That isn't altogether handy for TCG, since we'll be wanting to bswap
these buffers (probably in uint64_t chunks).
r~
--
To unsubscribe from this list: send the lin
On 11/06/2015 02:59 PM, Eduardo Habkost wrote:
Thanks! BTW, clflush uses gen_lea_modrm() too, does it do anything with
the address somewhere else?
Nope. It probably pre-dates the introduction of gen_nop_modrm.
r~
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body o
changed, 20 insertions(+), 8 deletions(-)
Reviewed-by: Richard Henderson
r~
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
if (!(s->cpuid_7_0_ebx_features & CPUID_7_0_EBX_CLWB))
+goto illegal_op;
+gen_lea_modrm(env, s, modrm);
You should use gen_nop_modrm here, since we're not going to do anything with
the address. Otherwise,
Reviewed-by: Richard Henderson
On 11/04/2015 08:35 PM, Eduardo Habkost wrote:
On Fri, Oct 30, 2015 at 01:54:33PM -0700, Richard Henderson wrote:
On 10/29/2015 12:31 AM, Xiao Guangrong wrote:
These instructions are used by NVDIMM drivers and the specification
locates at:
https://software.intel.com/sites/default/files/managed
ff-by: Xiao Guangrong
> ---
> target-i386/cpu.c | 8 +---
> target-i386/cpu.h | 3 +++
> 2 files changed, 8 insertions(+), 3 deletions(-)
Reviewed-by: Richard Henderson
Although it would be nice to update the comments in translate.c to include the
new insns, since they overlap
On 02/17/2015 06:24 AM, Michael Mueller wrote:
> +static inline uint64_t big_endian_bit(unsigned long nr)
> +{
> +return 1ul << (BITS_PER_LONG - (nr % BITS_PER_LONG));
> +};
This is buggy. NR=0 should map to 63, not 64.
> +return !!(*ptr & big_endian_bit(nr));
Personally I dislike !! as
On 02/17/2015 06:24 AM, Michael Mueller wrote:
> +/**
> + * s390_test_facility - test if given facility bit is set facility list
> + * of given cpu class
> + * @class: address of cpu class to test
> + * @nr: bit number to test
> + *
> + * Returns: true in case it is set
> + *
On 05/26/2014 03:20 AM, Andreas Färber wrote:
> Alpha is the main blocker for unifying CPU reset iirc. It does not
> implement reset at all and thus is not calling it. The struct was not
> designed for zero'ing things, so there's a mix of data fields and
> pointers without clear separation to allow
On 11/13/2013 08:53 AM, Paolo Bonzini wrote:
> Il 12/11/2013 19:54, Richard Henderson ha scritto:
>> For what it's worth, I think BOTH of the patches that have been posted
>> should be applied. That is, the patch that does (X || 1) -> (1 || X),
>> and the patch that
On 11/13/2013 03:04 AM, Anthony Liguori wrote:
> On Tue, Nov 12, 2013 at 8:08 AM, Peter Maydell
> wrote:
>> On 12 November 2013 15:58, Paolo Bonzini wrote:
>>> I don't really see a reason why QEMU should give clang more weight than
>>> Windows or Mac OS X.
>>
>> I'm not asking for more weight (a
$SUBJECT reminds me that the tcg s390x port is now prepared
to implement channel insns, but previously there were no
channels worth talking about:
/* I/O Instructions. For each we simply indicate non-operation. */
C(0xb276, XSCH,S, Z, 0, 0, 0, 0, subchannel, 0)
C(0xb230, CSCH
On 09/30/2011 10:07 AM, Chris Friesen wrote:
> We've been playing a bit with kvm-kmod-3.0b. We use a cross compile
> environment, and one of my coworkers noticed that the variables in
> config.mak weren't actually exported and so didn't actually have any
> effect.
Please elaborate on "no effect",
On 08/10/2011 09:24 AM, Richard Henderson wrote:
> Of course, as far as I can see, this variable is only used by
> the VGA devices. Surely we can arrange to pass down some address
> space during setup of the VGA?
... Which seems to be what you've done in patch 23.
So what'
On 08/08/2011 10:07 AM, Avi Kivity wrote:
> A helper that returns the address space used by ISA devices. Useful
> for getting rid of isa_mem_base, multiple ISA buses, or ISA buses behind
> bridges.
>
> Signed-off-by: Avi Kivity
> ---
> hw/isa-bus.c |6 ++
> hw/isa.h |1 +
> 2 fi
our favorite analogy of a windowing system, this is equivalent to
> dragging a subwindow off the left edge of the screen, and failing to clip
> it into its parent window which is on screen.
>
> Fix by switching to signed arithmetic.
>
> Signed-off-by: Avi Kivity
Signed-off-b
On 08/02/2011 03:06 PM, Avi Kivity wrote:
> I don't think there's any cpu which has a real 64-bit physical
> address space? Don't they all truncate it?
I don't know. You're right that x86_64 does, at 48 bits.
The alpha system I'm trying to emulate does, at 50 bits.
I guess if IBM agrees wrt p-se
On 08/02/2011 01:50 PM, Avi Kivity wrote:
> struct AddrRange {
> -uint64_t start;
> -uint64_t size;
> +int64_t start;
> +int64_t size;
I'm must say I'm not keen on this. My primary objection is that
a "range" can no longer properly represent the entire address space.
Or, indeed,
On 07/31/2011 10:57 AM, Avi Kivity wrote:
> +pci_register_bar_region(dev, 3, PCI_BASE_ADDRESS_SPACE_IO,
> +&d->cmd646_bar[2].cmd);
Typo: cmd646_bar[1].
r~
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger
kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory-region-b2
1-39
Reviewed-by: Richard Henderson
Nice cleanups.
r~
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/31/2011 10:57 AM, Avi Kivity wrote:
> +system_io = qemu_malloc(sizeof(*system_io));
> +memory_region_init(system_memory, "io", 65536);
> +set_system_io_map(system_io);
Cut-paste error on that second line.
r~
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
t
On 07/26/2011 04:36 AM, Paolo Bonzini wrote:
> On 07/26/2011 01:26 PM, Avi Kivity wrote:
>> +while (i < view->nr) {
>> +j = i + 1;
>> +while (j < view->nr
>> + && can_merge(&view->ranges[j-1], &view->ranges[j])) {
>> +view->ranges[i].addr.size += view->
ized as well, but it doesn't look worth bothering.
>
> Signed-off-by: Jan Kiszka
Reviewed-by: Richard Henderson
r~
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/16/2011 02:31 AM, Jan Kiszka wrote:
> ev.sigev_value.sival_int = 0;
> -ev.sigev_notify = SIGEV_SIGNAL;
> ev.sigev_signo = SIGALRM;
> +#ifdef SIGEV_THREAD_ID
> +if (qemu_signalfd_available()) {
> +ev.sigev_notify = SIGEV_THREAD_ID;
> +ev._sigev_un._tid = qemu_
On 06/15/2011 01:35 AM, Alexander Graf wrote:
>> -abi_ulong arg5 = 0, arg6 = 0, arg7 = 0, arg8 = 0;
>> +abi_ulong arg5 = 0, arg6 = 0;
>>
>> nb_args = mips_syscall_args[syscall_num];
>> sp_reg = env->active_tc.gpr[29];
>>
On 06/14/2011 10:36 AM, Michael S. Tsirkin wrote:
> Signed-off-by: Michael S. Tsirkin
> ---
> target-alpha/translate.c |7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
Acked-by: Richard Henderson
r~
--
To unsubscribe from this list: send the line "unsubs
On 06/14/2011 10:36 AM, Michael S. Tsirkin wrote:
> Signed-off-by: Michael S. Tsirkin
> ---
> target-alpha/translate.c |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
Acked-by: Richard Henderson
r~
--
To unsubscribe from this list: send the line "unsubscribe
On 05/31/2011 06:38 PM, Eduard - Gabriel Munteanu wrote:
> Hi,
>
> Again, sorry for taking so long, but I just don't send stuff without looking
> through it. This is meant to go into Michael's PCI branch, if it does.
>
> Some of the changes include:
> - some fixes (one thanks to David Gibson)
On 06/01/2011 08:35 AM, Eduard - Gabriel Munteanu wrote:
> Maybe it's not nice, but you're missing the fact upcasting gives you
> some type safety. With opaques you have none.
Lol. Do you understand what container_of does?
This is not dynamic_cast<> with RTTI.
You can put any type name in there
On 06/01/2011 07:29 AM, Avi Kivity wrote:
> On 06/01/2011 05:01 PM, Richard Henderson wrote:
>> > +err = dev->mmu->translate(dev, addr,&paddr,&plen, is_write);
>>
>> I see you didn't take my suggestion for using an opaque callback pointer.
>&
On 06/01/2011 07:52 AM, Eduard - Gabriel Munteanu wrote:
> The main selling point is there are more chances to screw up if every
> bus layer implements these manually. And it's really convenient,
> especially if we get to add another ld/st.
If we drop the ld/st, we're talking about 5 lines for eve
On 05/31/2011 06:38 PM, Eduard - Gabriel Munteanu wrote:
> +static inline void dma_memory_rw(DMADevice *dev,
> + dma_addr_t addr,
> + void *buf,
> + dma_addr_t len,
> + in
On 05/20/2011 07:31 AM, Anthony Liguori wrote:
> But is this a characteristic of devices or is this a characteristic of the
> chipset/CPU?
Chipset.
r~
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 05/20/2011 02:23 AM, Avi Kivity wrote:
> On 05/19/2011 11:43 PM, Anthony Liguori wrote:
>> On 05/19/2011 09:12 AM, Avi Kivity wrote:
>>> The memory API separates the attributes of a memory region (its size, how
>>> reads or writes are handled, dirty logging, and coalescing) from where it
>>> is
On 03/30/2010 01:20 AM, Eduard - Gabriel Munteanu wrote:
> +/* Ignore preexisting garbage in checksum. */
> +acpi_hdr = (struct acpi_table_header *) data;
> +sum -= acpi_hdr->checksum;
> +
> return (-sum) & 0xff;
Wouldn't it be cleaner to adjust the acpi_checksum definition to tak
t; "parse error: invalid keyword `unknowcmd'"
>
> Signed-off-by: Amos Kong
Acked-by: Richard Henderson
> ---
> json-parser.c |8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/json-parser.c b/json-parser.c
> index 57
On 03/16/2010 01:10 PM, Blue Swirl wrote:
> Just a tangential note: a long time ago, I tried to disable self
> modifying code detection for Sparc. On most RISC architectures, SMC
> needs explicit flushing so in theory we need not track code memory
> writes. However, during exceptions the translator
39 matches
Mail list logo
