On 2013-02-11 23:49, Marcelo Tosatti wrote:
> On Fri, Feb 01, 2013 at 10:47:37AM -0500, Jason J. Herne wrote:
>> On 01/24/2013 07:40 AM, Alexander Graf wrote:
>>> I think for now the best choice for get_regs() would be to ignore the
>>> FULL/RESET bits and always keep the syncing as it happens tod
On Fri, Feb 01, 2013 at 10:47:37AM -0500, Jason J. Herne wrote:
> On 01/24/2013 07:40 AM, Alexander Graf wrote:
> >I think for now the best choice for get_regs() would be to ignore the
> >FULL/RESET bits and always keep the syncing as it happens today under the
> >RUNTIME umbrella only. So all of
On 02/01/2013 10:47 AM, Jason J. Herne wrote:
On 01/24/2013 07:40 AM, Alexander Graf wrote:
I think for now the best choice for get_regs() would be to ignore the
FULL/RESET bits and always keep the syncing as it happens today under
the RUNTIME umbrella only. So all of get_regs() only checks for
On 01/24/2013 07:40 AM, Alexander Graf wrote:
I think for now the best choice for get_regs() would be to ignore the
FULL/RESET bits and always keep the syncing as it happens today under the
RUNTIME umbrella only. So all of get_regs() only checks for RUNTIME.
Whenever get_xxx() happens, a bit g
On Mon, Jan 28, 2013 at 12:49:26PM -0500, Jason J. Herne wrote:
> On 01/24/2013 07:01 PM, Marcelo Tosatti wrote:
> >On Thu, Jan 24, 2013 at 06:44:50PM -0200, Marcelo Tosatti wrote:
> >
> >What 'subtle errors' are you thinking of?
> >
> >It should be easy to convert as its greppable.
> >
> >>S/390 n
On 01/24/2013 07:01 PM, Marcelo Tosatti wrote:
On Thu, Jan 24, 2013 at 06:44:50PM -0200, Marcelo Tosatti wrote:
What 'subtle errors' are you thinking of?
It should be easy to convert as its greppable.
S/390 not synchronizing the env-> copy of the FULL register set is still
a bug, though (beca
On 25.01.2013, at 01:01, Marcelo Tosatti wrote:
> On Thu, Jan 24, 2013 at 06:44:50PM -0200, Marcelo Tosatti wrote:
>> On Thu, Jan 24, 2013 at 01:40:49PM +0100, Alexander Graf wrote:
read_reg(x)
if x not cached
arch_get_regs(RUNTIME_STATE) (*)
write_reg(x, v
On Thu, Jan 24, 2013 at 06:44:50PM -0200, Marcelo Tosatti wrote:
> On Thu, Jan 24, 2013 at 01:40:49PM +0100, Alexander Graf wrote:
> > > read_reg(x)
> > > if x not cached
> > > arch_get_regs(RUNTIME_STATE) (*)
> > >
> > > write_reg(x, val)
> > > read_reg(x)
> > > cpustate->x = val;
On 01/24/2013 12:22:56 PM, Peter Maydell wrote:
On 24 January 2013 18:17, Scott Wood wrote:
> On 01/24/2013 06:41:05 AM, Alexander Graf wrote:
>> But maybe the better solution would be a special "write to clear"
ONE_REG
>> register to clear specific bits and a big hammer "set" ONE_REG
(which
On Thu, Jan 24, 2013 at 01:40:49PM +0100, Alexander Graf wrote:
> > read_reg(x)
> > if x not cached
> > arch_get_regs(RUNTIME_STATE) (*)
> >
> > write_reg(x, val)
> > read_reg(x)
> > cpustate->x = val;
> > mark_dirty(x)
> >
> > Which is basically the pattern used in KV
On 24.01.2013, at 19:17, Scott Wood wrote:
> On 01/24/2013 06:41:05 AM, Alexander Graf wrote:
>> On 16.01.2013, at 18:23, Marcelo Tosatti wrote:
>> > What register is that and why it cannot be synced normally? When is it
>> > necessary to sync it?
>> We need to sync it on the above 2 occasions.
>
On 24.01.2013, at 19:22, Peter Maydell wrote:
> On 24 January 2013 18:17, Scott Wood wrote:
>> On 01/24/2013 06:41:05 AM, Alexander Graf wrote:
>>> But maybe the better solution would be a special "write to clear" ONE_REG
>>> register to clear specific bits and a big hammer "set" ONE_REG (which
On 24 January 2013 18:17, Scott Wood wrote:
> On 01/24/2013 06:41:05 AM, Alexander Graf wrote:
>> But maybe the better solution would be a special "write to clear" ONE_REG
>> register to clear specific bits and a big hammer "set" ONE_REG (which we
>> have already) for reset only.
>>
>> That would
On 01/24/2013 06:41:05 AM, Alexander Graf wrote:
On 16.01.2013, at 18:23, Marcelo Tosatti wrote:
> What register is that and why it cannot be synced normally? When is
it
> necessary to sync it?
We need to sync it on the above 2 occasions.
Thinking about this a bit more, we're trying to kee
On 16.01.2013, at 18:23, Marcelo Tosatti wrote:
> On Wed, Jan 16, 2013 at 05:00:52PM +, Bhushan Bharat-R65777 wrote:
>> I think above code should be:
>>kvm_arch_put_registers(cpu, cpu->kvm_vcpu_dirty);
>>cpu->kvm_vcpu_dirty = false;
>>
>> so vcpu will not enter guest
On 17.01.2013, at 00:01, Marcelo Tosatti wrote:
> On Wed, Jan 16, 2013 at 09:41:54PM +0100, Christian Borntraeger wrote:
>> On 16/01/13 21:21, Marcelo Tosatti wrote:
>>> On Wed, Jan 16, 2013 at 09:03:20PM +0100, Christian Borntraeger wrote:
On 16/01/13 17:05, Marcelo Tosatti wrote:
>>>
On Wed, Jan 16, 2013 at 09:41:54PM +0100, Christian Borntraeger wrote:
> On 16/01/13 21:21, Marcelo Tosatti wrote:
> > On Wed, Jan 16, 2013 at 09:03:20PM +0100, Christian Borntraeger wrote:
> >> On 16/01/13 17:05, Marcelo Tosatti wrote:
> >>
> >>> The S/390 problem, from
> >>> http://lists.nongnu.o
On 16/01/13 21:21, Marcelo Tosatti wrote:
> On Wed, Jan 16, 2013 at 09:03:20PM +0100, Christian Borntraeger wrote:
>> On 16/01/13 17:05, Marcelo Tosatti wrote:
>>
>>> The S/390 problem, from
>>> http://lists.nongnu.org/archive/html/qemu-devel/2012-11/msg02213.html:
>>>
>>> ">>> The kvm register syn
On Wed, Jan 16, 2013 at 05:00:52PM +, Bhushan Bharat-R65777 wrote:
> Second-)
> Currently kvm_arch_get_registers() is not optimized in two sense; one, it
> always get all registers from KVM; two, in kvm_arch_get_registers() it copies
> all registers to env->. This patch-set handles the second
On Wed, Jan 16, 2013 at 09:03:20PM +0100, Christian Borntraeger wrote:
> On 16/01/13 17:05, Marcelo Tosatti wrote:
>
> > The S/390 problem, from
> > http://lists.nongnu.org/archive/html/qemu-devel/2012-11/msg02213.html:
> >
> > ">>> The kvm register sync needs to happen in the kvm register sync
>
On 16/01/13 17:05, Marcelo Tosatti wrote:
> The S/390 problem, from
> http://lists.nongnu.org/archive/html/qemu-devel/2012-11/msg02213.html:
>
> ">>> The kvm register sync needs to happen in the kvm register sync
function :)
>>> That would eliminate the whole purpose of sync regs and forces
On Wed, Jan 16, 2013 at 05:00:52PM +, Bhushan Bharat-R65777 wrote:
> I think above code should be:
> kvm_arch_put_registers(cpu, cpu->kvm_vcpu_dirty);
> cpu->kvm_vcpu_dirty = false;
>
> so vcpu will not enter guest state with dirty registers in qemu.
Not so clear - cur
On Wed, Jan 16, 2013 at 02:05:33PM -0200, Marcelo Tosatti wrote:
> On Thu, Jan 10, 2013 at 10:29:04AM -0500, Jason J. Herne wrote:
> > From: "Jason J. Herne"
> >
> > do_kvm_cpu_synchronize_state is called via run_on_cpu, so we can only pass
> > a single argument. Create SyncStateArgs struct for
> -Original Message-
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> Sent: Wednesday, January 16, 2013 9:36 PM
> To: Jason J. Herne
> Cc: ag...@suse.de; borntrae...@de.ibm.com; aligu...@us.ibm.com; qemu-
> de...@nongnu.org; Bhushan Bharat-R65777; jan.kis...@siemens.com
> Subject: R
On Thu, Jan 10, 2013 at 10:29:04AM -0500, Jason J. Herne wrote:
> From: "Jason J. Herne"
>
> do_kvm_cpu_synchronize_state is called via run_on_cpu, so we can only pass
> a single argument. Create SyncStateArgs struct for this purpose and add
> register bitmap data member to it.
>
> Signed-off-b
> -Original Message-
> From: Jason J. Herne [mailto:jjhe...@us.ibm.com]
> Sent: Thursday, January 10, 2013 8:59 PM
> To: ag...@suse.de; borntrae...@de.ibm.com; aligu...@us.ibm.com;
> mtosa...@redhat.com; qemu-devel@nongnu.org; Bhushan Bharat-R65777;
> jan.kis...@siemens.com
> Cc: Jason J.
On Thu, Jan 10, 2013 at 3:29 PM, Jason J. Herne wrote:
> From: "Jason J. Herne"
>
> do_kvm_cpu_synchronize_state is called via run_on_cpu, so we can only pass
> a single argument. Create SyncStateArgs struct for this purpose and add
> register bitmap data member to it.
>
> Signed-off-by: Jason J
From: "Jason J. Herne"
do_kvm_cpu_synchronize_state is called via run_on_cpu, so we can only pass
a single argument. Create SyncStateArgs struct for this purpose and add
register bitmap data member to it.
Signed-off-by: Jason J. Herne
Reviewed-by: Christian Borntraeger
---
include/sysemu/kvm
28 matches
Mail list logo
