lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150519133240.GA32489@potion.brq.redhat.com>
Date:	Tue, 19 May 2015 15:32:41 +0200
From:	Radim Krčmář <rkrcmar@...hat.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Xiao Guangrong <guangrong.xiao@...ux.intel.com>,
	bdas@...hat.com
Subject: Re: [PATCH 08/11] KVM: implement multiple address spaces

2015-05-18 15:48+0200, Paolo Bonzini:
> +If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 of "slot"
> +specifies the address space which is being modified.  They must be
> +less than the value that KVM_CHECK_EXTENSION returns for the
> +KVM_CAP_MULTI_ADDRESS_SPACE capability.

> +                                         Slots in separate address spaces
> +are unrelated;

I'd prefer to decouple address spaces and slots.  KVM_GET_DIRTY_LOG
could stay the same if we said that a slot can be in multiple address
spaces.  (Well, we could do that even now, by searching for slots that
differ only in address space id and pointing them to same dirty bitmap.
This even makes sense, which is a sign of lacking design :)

The main drawback is that forcing decoupling on existing IOCTLs would be
really awkward ... we'd need to have new API for address spaces;
there are two basic operations on an address space:
  add and remove slot (needs: slot id, address space id)
which would give roughly the same functionality as this patch.
(To maximixe compatibility, there could be a default address space and a
 slot flag that doesn't automatically add it there.)

On top of this, we could allow hierarchical address spaces, so very similar
address spaces (like SMM) would be easier to set up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ