On 26.04.2021 09:12, Paul Durrant wrote:
> On 22/04/2021 16:11, Jan Beulich wrote:
>> On 22.04.2021 17:06, Jan Beulich wrote:
>>> On 22.04.2021 16:55, Jan Beulich wrote:
+do {
+/* Limit rows to just as many to cover the next one to
access. */
+cf
On 22/04/2021 16:11, Jan Beulich wrote:
On 22.04.2021 17:06, Jan Beulich wrote:
On 22.04.2021 16:55, Jan Beulich wrote:
+do {
+/* Limit rows to just as many to cover the next one to access. */
+cfg->start_row = i;
+cfg->rows[modrm_reg] = i + 1;
+
On 22.04.2021 17:06, Jan Beulich wrote:
> On 22.04.2021 16:55, Jan Beulich wrote:
>> +do {
>> +/* Limit rows to just as many to cover the next one to access.
>> */
>> +cfg->start_row = i;
>> +cfg->rows[modrm_reg] = i + 1;
>> +write_tilecfg(cf
Paul,
On 22.04.2021 16:55, Jan Beulich wrote:
> +do {
> +/* Limit rows to just as many to cover the next one to access. */
> +cfg->start_row = i;
> +cfg->rows[modrm_reg] = i + 1;
> +write_tilecfg(cfg);
> +
> +if ( vex.pfx != vex_f
In order to be flexible about future growth of tile dimensions, use a
separately allocated scratch buffer to read/write individual rows of a
tile.
Note that the separate write_tilecfg() function is needed because
LDTILECFG wouldn't serve the purpose: It clears various state, unlike
XRSTOR / XRSTOR
