Re: [PATCH] [RFC] vpci: allow BAR write while mapped

2025-03-17 Thread Alejandro Vallejo
On Mon Mar 17, 2025 at 12:32 PM GMT, Roger Pau Monné wrote: > On Fri, Mar 14, 2025 at 10:39:04AM +, Alejandro Vallejo wrote: > > On Thu Mar 13, 2025 at 5:43 PM GMT, Stewart Hildebrand wrote: > > > I think this just reinforces the need to rework the BAR mapping > > > machinery. > > > > Right. T

Re: [PATCH] [RFC] vpci: allow BAR write while mapped

2025-03-17 Thread Roger Pau Monné
On Fri, Mar 14, 2025 at 10:39:04AM +, Alejandro Vallejo wrote: > On Thu Mar 13, 2025 at 5:43 PM GMT, Stewart Hildebrand wrote: > > I think this just reinforces the need to rework the BAR mapping > > machinery. > > Right. The most delicate part is dealing with races with another vCPU when the >

Re: [PATCH] [RFC] vpci: allow BAR write while mapped

2025-03-14 Thread Alejandro Vallejo
On Thu Mar 13, 2025 at 5:43 PM GMT, Stewart Hildebrand wrote: > The idea was that the unmap-then-map operation would appear atomic from > the guest's point of view. I've only queued up the unmap operation at > this point in the new logic. Due to the mentioned limitation in the BAR > mapping deferra

Re: [PATCH] [RFC] vpci: allow BAR write while mapped

2025-03-14 Thread Jan Beulich
On 13.03.2025 18:48, Roger Pau Monné wrote: > On Wed, Mar 12, 2025 at 03:50:17PM -0400, Stewart Hildebrand wrote: >> @@ -585,10 +601,31 @@ static void cf_check bar_write( >> { >> /* If the value written is the current one avoid printing a >> warning. */ >> if ( val != (uint3

Re: [PATCH] [RFC] vpci: allow BAR write while mapped

2025-03-14 Thread Jan Beulich
On 14.03.2025 09:21, Roger Pau Monné wrote: > On Fri, Mar 14, 2025 at 09:04:55AM +0100, Jan Beulich wrote: >> On 13.03.2025 18:48, Roger Pau Monné wrote: >>> On Wed, Mar 12, 2025 at 03:50:17PM -0400, Stewart Hildebrand wrote: @@ -585,10 +601,31 @@ static void cf_check bar_write( { >>

Re: [PATCH] [RFC] vpci: allow BAR write while mapped

2025-03-14 Thread Roger Pau Monné
On Fri, Mar 14, 2025 at 09:04:55AM +0100, Jan Beulich wrote: > On 13.03.2025 18:48, Roger Pau Monné wrote: > > On Wed, Mar 12, 2025 at 03:50:17PM -0400, Stewart Hildebrand wrote: > >> @@ -585,10 +601,31 @@ static void cf_check bar_write( > >> { > >> /* If the value written is the curr

Re: [PATCH] [RFC] vpci: allow BAR write while mapped

2025-03-13 Thread Stewart Hildebrand
On 3/13/25 13:48, Roger Pau Monné wrote: > On Wed, Mar 12, 2025 at 03:50:17PM -0400, Stewart Hildebrand wrote: >> Xen vPCI refuses BAR writes if the BAR is mapped in p2m. If firmware >> initialized the BAR to a bad address, Linux will try to write a new >> address to the BAR without disabling memor

Re: [PATCH] [RFC] vpci: allow BAR write while mapped

2025-03-13 Thread Roger Pau Monné
On Wed, Mar 12, 2025 at 03:50:17PM -0400, Stewart Hildebrand wrote: > Xen vPCI refuses BAR writes if the BAR is mapped in p2m. If firmware > initialized the BAR to a bad address, Linux will try to write a new > address to the BAR without disabling memory decoding. Allow the write > by updating p2m

Re: [PATCH] [RFC] vpci: allow BAR write while mapped

2025-03-13 Thread Roger Pau Monné
On Thu, Mar 13, 2025 at 03:14:26PM +, Alejandro Vallejo wrote: > On Wed Mar 12, 2025 at 7:50 PM GMT, Stewart Hildebrand wrote: > > Xen vPCI refuses BAR writes if the BAR is mapped in p2m. If firmware > > initialized the BAR to a bad address, Linux will try to write a new > > address to the BAR

Re: [PATCH] [RFC] vpci: allow BAR write while mapped

2025-03-13 Thread Stewart Hildebrand
On 3/13/25 11:14, Alejandro Vallejo wrote: > On Wed Mar 12, 2025 at 7:50 PM GMT, Stewart Hildebrand wrote: >> Xen vPCI refuses BAR writes if the BAR is mapped in p2m. If firmware >> initialized the BAR to a bad address, Linux will try to write a new >> address to the BAR without disabling memory de

Re: [PATCH] [RFC] vpci: allow BAR write while mapped

2025-03-13 Thread Alejandro Vallejo
On Wed Mar 12, 2025 at 7:50 PM GMT, Stewart Hildebrand wrote: > Xen vPCI refuses BAR writes if the BAR is mapped in p2m. If firmware > initialized the BAR to a bad address, Linux will try to write a new > address to the BAR without disabling memory decoding. Allow the write > by updating p2m right