On Mon, 14 Jan 2019 at 01:08, Aleksandar Markovic
wrote:
> I do understand the definition of cluster_index in the sense
> of this series. However, it looks to me that the term
> "cluster" is generally overused in areas where we work.
> This may lead to some confusion for future developers, and
>
On Mon, 14 Jan 2019 at 01:08, Aleksandar Markovic
wrote:
>
>
>
> On Tuesday, January 8, 2019, Peter Maydell wrote:
>>
>> Include the cluster number in the hash we use to look
>> up TBs. This is important because a TB that is valid
>> for one cluster at a given physical address and set
>> of CPU
On Tuesday, January 8, 2019, Peter Maydell wrote:
> Include the cluster number in the hash we use to look
> up TBs. This is important because a TB that is valid
> for one cluster at a given physical address and set
> of CPU flags is not necessarily valid for another:
> the two clusters may have
On Friday, January 11, 2019, Peter Maydell wrote:
> On Fri, 11 Jan 2019 at 12:49, Aleksandar Markovic
> wrote:
> > 1. What would be, in more detail, if possible in layman terms,
> > the "bad case" that this series fixes?
>
> I describe this in the cover letter (which also has a link to
> a
On Fri, 11 Jan 2019 at 12:49, Aleksandar Markovic
wrote:
> 1. What would be, in more detail, if possible in layman terms,
> the "bad case" that this series fixes?
I describe this in the cover letter (which also has a link to
a tarball with a test case demonstrating it):
> TCG implicitly assumes
Hello, Peter.
First of all, I want to tell you that I support this series and I salute
efforts in this and related areas. It is known that there have been strong
trends towards asymmetric multi-core systems now for some longish time -
and that QEMU support in that area will greately enhance QEMU
On Tue, 8 Jan 2019 at 16:30, Peter Maydell wrote:
>
> Include the cluster number in the hash we use to look
> up TBs. This is important because a TB that is valid
> for one cluster at a given physical address and set
> of CPU flags is not necessarily valid for another:
> the two clusters may have
On 1/8/19 5:30 PM, Peter Maydell wrote:
> Include the cluster number in the hash we use to look
> up TBs. This is important because a TB that is valid
> for one cluster at a given physical address and set
> of CPU flags is not necessarily valid for another:
> the two clusters may have different
Include the cluster number in the hash we use to look
up TBs. This is important because a TB that is valid
for one cluster at a given physical address and set
of CPU flags is not necessarily valid for another:
the two clusters may have different views of physical
memory, or may have different CPU
