[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] X86 arch_domain ginormous, sizeof(struct domain) already == PAGE_SIZE
- To: "Lengyel, Tamas" <tlengyel@xxxxxxxxxxx>
- From: Corneliu ZUZU <czuzu@xxxxxxxxxxxxxxx>
- Date: Fri, 29 Jan 2016 23:32:42 +0200
- Cc: Jan Beulich <jbeulich@xxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxx>
- Comment: DomainKeys? See http://domainkeys.sourceforge.net/
- Delivery-date: Fri, 29 Jan 2016 21:33:15 +0000
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=008MUfpVwjK2IblJWrJ5zyoi1pN9NHmkJbzpPleeE47XMoyAJ+kLsPB75vqsI+JrxG6WanNbbrQJhA2Y+7oBXglosXTpNqcGYipCsRDKqeTVJ5lK9psZEoqvtJsreMsrm4K43A1PWC5Y7jUqpHcsqprxy0X/Aex+x3fCQddem3X2db7Kx4folDcOz2/kA8hgRmx7gYXH5LI9KvZ+dR0hNthFUaPzW7K6ubTYWWz7Ge4hbzRwpSeHPZkSy57RNXi/N4jgzWgJjLjMQ8UNOBO9+eeee0Q4a3ouJKB2ccEOALWAfH/FM5NRTkL/71L2uFM1CknlR+ihtYSzV2Vm4h4BYw==; h=Received:Received:Received:Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 1/29/2016 6:47 PM, Lengyel, Tamas
wrote:
Conceptually speaking, they are not X86-specific. Single-stepping,
software-breakpoints, guest-to-hypervisor notifications,
control/system registers - these are concepts that are not strictly
confined exclusively within a single architecture, whereas for
example MSRs are. It's true that originally the need for defining 4
bits for 4 control-registers came because those 4 registers were the
X86 CR0, CR3, CR4 & XCR0 registers, but I was not suggesting to
keep the same significance after this change.
Rather, my proposition was-to-be (when sending the move-to-common
patch) either:
1). to change that significance to "for now, 4 bits are enough to
cover all the monitored control-registers for all the architectures
that implement vm-event control register monitoring. If, in the
future an implementation change of control-register monitoring for
an architecture will require more than the # of bits @ that time,
then that # can be adjusted."
2). define a single upper limit for control-registers count for all
architectures, e.g. smth like #define MONITOR_CTRLREG_MAX_COUNT 8 -
maybe paired w/ ASSERT/BUG_ON_BUILD-like checks to enforce that
and/or avoid undesired behavior.
Or maybe some other way, nonetheless, as I said, IMO the place for
these bits could be here, in the common code, since conceptually
they could apply to any architecture.
I was actually hoping to approach this matter after the
move-to-common patch because I have another patch I would like to
put forward that implements control-registers monitoring on ARM as
well and incidentally there are also 4 of them in that patch, as on
X86. But that's to come :).
Corneliu.
|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|