From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juan Quintela Subject: KVM call minutes for 2013-07-23 Date: Tue, 23 Jul 2013 18:29:20 +0200 Message-ID: <87y58xnstb.fsf@elfo.elfo> Reply-To: quintela@redhat.com Mime-Version: 1.0 Content-Type: text/plain To: KVM devel mailing list , qemu-devel qemu-devel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:12614 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932595Ab3GWQ3c (ORCPT ); Tue, 23 Jul 2013 12:29:32 -0400 Sender: kvm-owner@vger.kernel.org List-ID: - Or how to confuse dates: I am very good at it (quintela) Sorry again. - Organizational trivia: We are changing the call number details If you don't receive an invite in the following days, let me now. - s390: has different reset interfaces (only cpus, also memory, some devices) They need to reset some specific subsystems and not others (or the other way around, reset everything except ...) In x86: soft reset: reset only the cpu, not the devices (keyboard controller reset). Reset at top level resets everything. And you can reset things a subsystem (for instance pci) with qdev. So the infrastructure should be there. In some platforms they need to regenerate the device tree after reset, so there is a reset_hook() for stuff like that. How to reset all devices except CPU? What event should we generate for each reset type? We can use qdev_reset() to behave as we want. What to do with non qdev devices? Write to one register in the ppc machine.